[Chicago] Prudence

Tal Liron tal.liron at threecrickets.com
Mon Sep 27 20:51:36 CEST 2010



Prudence assumes nothing. It's up to you, as a developer, to make sure 
your threads don't hang. I know of no web framework that can save you 
from that responsibility. At best, perhaps you can get a warning about 
overly long request handling. (Though, a hanging application is a good 
enough warning...)

The actual handling of requests is done by Grizzly (which can be 
replaced with Jetty or Netty) and Restlet on top of it. I'm an active 
contributor to Restlet, and am happy to say that we have some of the 
best thinkers about concurrency on board. The work on asynchronous 
handling (which is key to Prudence's conversation.defer API) is still in 
the initial phases: the structures along the way are thread safe, but 
there's a problem with response processing that could lead to 
indeterminate (thread-safe) states. This is something that will be 
addressed better in the next version of Restlet, and thus Prudence. 
Though, as I'll keep reminding everyone, asynchronous handling is a cute 
feature that actually isn't all that useful.

Thanks for the doc compliment! Many, many hours were spent on writing it...


I write all my documentation in LyX, which is essentially LaTeX. The LyX 
source and generated (100-page) PDF are part of the Prudence download. I 
then run eLyXer (a Python app) to turn LyX into a single HTML page, and 
then have my own script do its regex magic to make that single page into 
something more webby, which is what you see in the online manual.


The nice thing is that I use a real word processor, which is a pleasure, 
and then can generate both online documentation and a beautifully 
printed book from it. It's the only way I document these days. Though, 
I've heard really good things about reStructuredText.


-Tal


On 09/27/2010 01:09 PM, Daniel Griffin wrote:

> So you just push the processing of each request off into a thread pool 
> or are you assuming each request is short?
>
> 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.
>
>
>
> On Mon, Sep 27, 2010 at 12:49 PM, Tal Liron 
> <tal.liron at threecrickets.com <mailto:tal.liron at threecrickets.com>> wrote:
>
>      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'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.
>
>     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
>     "deferred conversations," 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 "please wait" page to
>     the user, which will continue polling your site until it gets a
>     result. Think of something like Travelocity's "searching for you
>     flights" page.
>
>     I deal with the issue in some depth in the chapter "Scaling Tips"
>     in the Prudence Manual:
>
>     http://threecrickets.com/prudence/scaling/#toc-Subsection-89
>
>     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'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 "dynamic" web pages is saturated, and you're just
>     returning static cached pages to some users, then your application
>     may seem to work, but is in fact quite broken. You haven't solved
>     your scaling problem, just put a bandaid on it.
>
>     Also, though non-blocking I/O is interesting (and hard to do) it'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.
>
>     -Tal
>
>
>     On 09/27/2010 10:21 AM, Daniel Griffin wrote:
>
>         +1 for something really cool.
>
>         How do you reconcile non-blocking I/O with blocking database
>         calls?
>
>
>         On Mon, Sep 27, 2010 at 10:17 AM, Trent Jurewicz
>         <tjurewicz at gmail.com <mailto:tjurewicz at gmail.com>
>         <mailto:tjurewicz at gmail.com <mailto:tjurewicz at gmail.com>>> wrote:
>
>            +1 to hear more about prudence in general and the caching layer
>            implemented...
>
>
>            On Mon, Sep 27, 2010 at 3:18 AM, Tal Liron
>         <tal.liron at threecrickets.com
>         <mailto:tal.liron at threecrickets.com>
>         <mailto:tal.liron at threecrickets.com
>         <mailto:tal.liron at threecrickets.com>>>
>
>            wrote:
>
>
>
>                Hey ChiPy,
>
>
>                After more than a year of development, I'm happy to
>         announce a
>                release candidate for Prudence:
>
>
>         http://threecrickets.com/prudence/
>
>
>                Yes, yet another web development framework for Python.
>         Yawn.
>                But this one is a bit different:
>
>
>                1. Embraces the JVM. That means Jython-centric, with some
>                limited support for Jepp (real CPython on the JVM, bleh).
>
>                2. Designed ground-up for REST. Nothing about HTTP is
>         hidden
>                from you. You know, HTTP is actually really useful.
>
>                3. Non-blocking I/O and other adult thinking about
>         concurrency.
>
>                4. Probably the most sophisticated caching system
>         you've seen
>                in a web development platform.
>
>                5. No data layer -- add your own. The example app uses
>                SQLAlchemy. (I have other apps talking to MongoDB.)
>
>                6. Ready-to-rumble package -- just download, and will
>         run on
>                any JVM platform. Tested on Linux, OpenSolaris, OS X and
>                Windows. Ubuntu repository FTW.
>
>
>                I'd be happy to give a presentation to ChiPy on "Advanced
>                Caching with Prudence". Even if you never use Prudence, you
>                might get jealous and try to implement some of these
>         tricks in
>                your own platform of choice.
>
>
>                Can I get a +1?
>
>
>                A future presentation could also be about Scripturian, the
>                underlying library that makes Jython work well in highly
>                concurrent environments. I had to do a lot of hacking
>         in the
>                Jython source code, and learn things that no man should
>         have
>                to know.
>
>
>                Love,
>
>                Tal
>
>                _______________________________________________
>                Chicago mailing list
>         Chicago at python.org <mailto:Chicago at python.org>
>         <mailto:Chicago at python.org <mailto:Chicago at python.org>>
>
>         http://mail.python.org/mailman/listinfo/chicago
>
>
>
>            _______________________________________________
>            Chicago mailing list
>         Chicago at python.org <mailto:Chicago at python.org>
>         <mailto:Chicago at python.org <mailto:Chicago at python.org>>
>
>         http://mail.python.org/mailman/listinfo/chicago
>
>
>
>         _______________________________________________
>         Chicago mailing list
>         Chicago at python.org <mailto:Chicago at python.org>
>         http://mail.python.org/mailman/listinfo/chicago
>
>     _______________________________________________
>     Chicago mailing list
>     Chicago at python.org <mailto:Chicago at python.org>
>     http://mail.python.org/mailman/listinfo/chicago
>
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> http://mail.python.org/mailman/listinfo/chicago


More information about the Chicago mailing list