Hi, Am Donnerstag, den 08.03.2007, 01:40 -0300 schrieb Sidnei da Silva:
On 3/7/07, Christian Theune <ct@gocept.com> wrote:
Right. This optimization is about leveraging the fact that in many situations the upstream bandwith is *much* lower than the IO bandwith to the disk.
Another condition that I have (and I think this is the general pattern) is that application threads should be given back to the pool as quickly as possible.
If 5 seconds are spend in the application thread to untangle mime data which has nothing application-specific about it and then only 100ms or so in the application itself, I'd say there is a major overhead problem.
I had came to the same conclusion a couple weeks ago, somehow *wink*. Maybe we've been influenced by the same person. :)
So if the uploaded file shouldn't be handled by the application thread, neither by the IO layer, then I guess we need a 'upload handling thread pool' of some sorts, whose sole purpose is to handle incoming requests that are large before it gets to the application thread while still outside the async IO layer.
I really wonder whether that's necessary. Actually. I'll take a look around the other web frameworks and check how they do their REQUEST processing. Maybe I can learn something from that.
Hopefully something similar could be done for files being sent *out* of the application when they don't need any application processing anymore (ie, Blobs!).
We already have that. The FileStreamIterator allows you to hand out an iterable that will be used outside the application thread to stream data from. Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - ct@gocept.com - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development