[Zope-dev] Early processing of request body (was: Proposal for optimized Blob handling)

Christian Theune ct at gocept.com
Sun Mar 11 06:39:53 EDT 2007


Hi,

Am Samstag, den 10.03.2007, 07:36 +0100 schrieb Dieter Maurer:
> Christian Theune wrote at 2007-3-7 22:05 +0100:
> > ...
> >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.
> 
> But if the IO thread spends 5 seconds, then Zope will be unresponsive
> for 5 seconds -- for me (and hopefully others, too) a far more
> critical situation than a (single) worker spending 5 seconds...
> 
> The IO (ZServer) thread should only perform minimal work in its
> "asyncore" callbacks -- each callback should return within
> a few milliseconds.
> 
> 
> My argument does not argue against different threads between
> the IO thread and the worker threads, just against giving
> the IO thread significant work (whether or not you consider it
> application specific).

Ah. Maybe I didn't point this out enough. I was thinking about switching
to a "chunk-based" approach on processing the request. That way I want
to avoid having to process large file data twice.

IMHO a variation of the FieldStorage could be implemented that processes
the data line by line as it comes in. That would avoid the 5 sec. delay
if you process it at once and should not be a problem in the IO thread.

Christian

-- 
gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20070311/28e3eeeb/attachment.bin


More information about the Zope-Dev mailing list