[Zope-dev] ZPT Optimization Opportunity
tseaver at zope.com
Mon Sep 27 14:31:43 EDT 2004
Jim Fulton wrote:
> Tres Seaver wrote:
>> - Returning the iterator to medusa means that the application
>> thread becomes available to service other threads that much more
>> quickly. Even if the malloc issues can't be demonstrated, the
>> increase in concurrency *should* be a win here.
> I don't think this would affect application threads.
> The application thread is freed as soon as the ZPT template
> completed rendering. This will be the same whether we dribbled
> data out as we go, or not.
The appserver thread still has to the "assembly" (malloc + copy) work to
return a Big String response to medusa; I'm trying to avoid that.
> The potential benefit is that we could get the page back to the
> browser faster and thus reduce the number of open connection
> that asyncore has to manage. This benefit will be difficult
> to obtain unless the publisher supports streaming outbut via
> chunks. (I doubt that it does, but I don't really know.)
lib/python/ZPublisher/Iterators.py does that (but it isn't for "lazy"
rendering, because, as you point out, it needs to know the content length).
> Without output chunking, the server can't start sending
> output until the content length is known and it can't know
> that until the template has been fully generated.
My proposal isn't to begin sending content back before the rendering is
complete; I just want to avoid copying the content from the
list-of-many-small-strings (StringIO's 'buflist') to a single BigString.
The IStreamIterator interface allows me to avoid the malloc+copy part;
the appserver thread would be done as soon as the last ZPT opcode
Tres Seaver tseaver at zope.com
Zope Corporation "Zope Dealers" http://www.zope.com
More information about the Zope-Dev