So you just push the processing of each request off into a thread pool or are you assuming each request is short?<div><br></div><div>Also, way to write doc that actually explains what this does. This trend of people generating pydoc or whatever and thinking they are set is awful. </div>
<div><br></div><div><br><br><div class="gmail_quote">On Mon, Sep 27, 2010 at 12:49 PM, Tal Liron <span dir="ltr">&lt;<a href="mailto:tal.liron@threecrickets.com">tal.liron@threecrickets.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
 The truth is that non-blocking I/O is not a big deal for web applications. Somewhere at the top, you /always/ have a thread pool. In order to do anything meaningful to generate a page dynamically, you will have a single thread going through some code, which you&#39;ll want to release ASAP. A user generates a hit with a browser, and generates a tiny response. Breaking it up to multiple calling threads will not help anything -- it will just create a data synchronization burden for you, which is already considerable in a multi-threaded environment, such as Prudence.<br>

<br>
When it comes down to it, there are actually very few use cases for pure non-threaded I/O on the Internet: streaming media, or media in general -- basically anything /static/. Prudence does have (experimental) support in version 1.0 for something called &quot;deferred conversations,&quot; in which you can release the current thread and commit it whenever you feel like it. But ... what kind of user experience is that? The user will be waiting for your web page to return, and meanwhile watch the browser spin. If you have a potentially long request, you are far better off putting something on a task queue, and returning a &quot;please wait&quot; page to the user, which will continue polling your site until it gets a result. Think of something like Travelocity&#39;s &quot;searching for you flights&quot; page.<br>

<br>
I deal with the issue in some depth in the chapter &quot;Scaling Tips&quot; in the Prudence Manual:<br>
<br>
<a href="http://threecrickets.com/prudence/scaling/#toc-Subsection-89" target="_blank">http://threecrickets.com/prudence/scaling/#toc-Subsection-89</a><br>
<br>
Where non-blocking I/O can help a pure web app is: delivering media (if you really want to do it from the same server... not necessarily recommended, but possible), and more graceful handling of failure. In my ideal, Prudence&#39;s I/O frontend would be able to talk directly to the caching layer (on the roadmap), but even that is hard to recommend as such a great feature. If the thread pool handling the &quot;dynamic&quot; web pages is saturated, and you&#39;re just returning static cached pages to some users, then your application may seem to work, but is in fact quite broken. You haven&#39;t solved your scaling problem, just put a bandaid on it.<br>

<br>
Also, though non-blocking I/O is interesting (and hard to do) it&#39;s not even that necessary anymore. Modern kernels (Linux especially) do a fabulous job handling many thousands of rotating threads. If you look at a few of the high-scalability web servers available for Linux, some of the best performing and scaling ones are those based on threads, not async.<br>

<br>
-Tal<div class="im"><br>
<br>
On 09/27/2010 10:21 AM, Daniel Griffin wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
+1 for something really cool.<br>
<br>
How do you reconcile non-blocking I/O with blocking database calls?<br>
<br>
<br></div><div class="im">
On Mon, Sep 27, 2010 at 10:17 AM, Trent Jurewicz &lt;<a href="mailto:tjurewicz@gmail.com" target="_blank">tjurewicz@gmail.com</a> &lt;mailto:<a href="mailto:tjurewicz@gmail.com" target="_blank">tjurewicz@gmail.com</a>&gt;&gt; wrote:<br>

<br>
    +1 to hear more about prudence in general and the caching layer<br>
    implemented...<br>
<br>
<br>
    On Mon, Sep 27, 2010 at 3:18 AM, Tal Liron<br></div>
    &lt;<a href="mailto:tal.liron@threecrickets.com" target="_blank">tal.liron@threecrickets.com</a> &lt;mailto:<a href="mailto:tal.liron@threecrickets.com" target="_blank">tal.liron@threecrickets.com</a>&gt;&gt;<div><div>
</div><div class="h5"><br>
    wrote:<br>
<br>
<br>
<br>
        Hey ChiPy,<br>
<br>
<br>
        After more than a year of development, I&#39;m happy to announce a<br>
        release candidate for Prudence:<br>
<br>
<br>
        <a href="http://threecrickets.com/prudence/" target="_blank">http://threecrickets.com/prudence/</a><br>
<br>
<br>
        Yes, yet another web development framework for Python. Yawn.<br>
        But this one is a bit different:<br>
<br>
<br>
        1. Embraces the JVM. That means Jython-centric, with some<br>
        limited support for Jepp (real CPython on the JVM, bleh).<br>
<br>
        2. Designed ground-up for REST. Nothing about HTTP is hidden<br>
        from you. You know, HTTP is actually really useful.<br>
<br>
        3. Non-blocking I/O and other adult thinking about concurrency.<br>
<br>
        4. Probably the most sophisticated caching system you&#39;ve seen<br>
        in a web development platform.<br>
<br>
        5. No data layer -- add your own. The example app uses<br>
        SQLAlchemy. (I have other apps talking to MongoDB.)<br>
<br>
        6. Ready-to-rumble package -- just download, and will run on<br>
        any JVM platform. Tested on Linux, OpenSolaris, OS X and<br>
        Windows. Ubuntu repository FTW.<br>
<br>
<br>
        I&#39;d be happy to give a presentation to ChiPy on &quot;Advanced<br>
        Caching with Prudence&quot;. Even if you never use Prudence, you<br>
        might get jealous and try to implement some of these tricks in<br>
        your own platform of choice.<br>
<br>
<br>
        Can I get a +1?<br>
<br>
<br>
        A future presentation could also be about Scripturian, the<br>
        underlying library that makes Jython work well in highly<br>
        concurrent environments. I had to do a lot of hacking in the<br>
        Jython source code, and learn things that no man should have<br>
        to know.<br>
<br>
<br>
        Love,<br>
<br>
        Tal<br>
<br>
        _______________________________________________<br>
        Chicago mailing list<br></div></div>
        <a href="mailto:Chicago@python.org" target="_blank">Chicago@python.org</a> &lt;mailto:<a href="mailto:Chicago@python.org" target="_blank">Chicago@python.org</a>&gt;<div class="im"><br>
        <a href="http://mail.python.org/mailman/listinfo/chicago" target="_blank">http://mail.python.org/mailman/listinfo/chicago</a><br>
<br>
<br>
<br>
    _______________________________________________<br>
    Chicago mailing list<br></div>
    <a href="mailto:Chicago@python.org" target="_blank">Chicago@python.org</a> &lt;mailto:<a href="mailto:Chicago@python.org" target="_blank">Chicago@python.org</a>&gt;<div class="im"><br>
    <a href="http://mail.python.org/mailman/listinfo/chicago" target="_blank">http://mail.python.org/mailman/listinfo/chicago</a><br>
<br>
<br>
<br>
_______________________________________________<br>
Chicago mailing list<br>
<a href="mailto:Chicago@python.org" target="_blank">Chicago@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/chicago" target="_blank">http://mail.python.org/mailman/listinfo/chicago</a><br>
</div></blockquote><div><div></div><div class="h5">
_______________________________________________<br>
Chicago mailing list<br>
<a href="mailto:Chicago@python.org" target="_blank">Chicago@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/chicago" target="_blank">http://mail.python.org/mailman/listinfo/chicago</a><br>
</div></div></blockquote></div><br></div>