[Zope-dev] ZPT Optimization Opportunity

[Tres Seaver]

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 
completes.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com