[ZCM] [ZC] 272/ 3 Comment "RESPONSE.write enhancements"

[Collector: Zope Bugs and Patches ...]

Issue #272 Update (Comment) "RESPONSE.write enhancements"
 Status Accepted, ZServer/feature+solution medium
To followup, visit:
  http://collector.zope.org/Zope/272

==============================================================
= Comment - Entry #3 by htrd on Mar 11, 2002 7:09 am

smallchunks.diff merged into the trunk for 2.6
________________________________________
= Comment - Entry #2 by htrd on Mar 11, 2002 6:57 am


Uploaded:  "smallchunks.diff"
 - http://collector.zope.org/Zope/272/smallchunks.diff/view
Here is the patch for the second element of this change: small chunks bypassing the temporary file
________________________________________
= Request - Entry #1 by htrd on Mar 7, 2002 3:23 am

 Status: Pending => Accepted

 Supporters added: htrd

Resurrecting two patches that never got merged from the old collector:

1. RESPONSE.write currently uses a temporary file to buffer output if a Content-Length header is set to a large value. However sometimes you know the output will be large enough to need a temporary file, but you dont know the exact size. This patch allows a method to overide a RESPONSE._approximate_content_length, which will be used by the RESPONSE object when working out what type of buffering to use if the Content-Length header is not set.

2. Temporary files are used when whole output is large, and the REPONSE object doesnt want to keep it all in memory. If a temp file has been opened, RESPONSE.write always writes is parameter to the file, and inserts a class instance in the producer queue indicating which byte range to read from the file. This will save memory if the parameter to RESPONSE.write is large, however it will drastically increase memory usage if the parameter to RESPONSE.write are small, and RESPONSE.write is called many times. 

This patch changes RESPONSE.write to use bypass the temporary file for small chunks, less than 200 bytes, and writes them direct to the producer queue. This is an optimisation with no downside: it is always cheaper to store a 200 byte chunk in memory, rather than a class instance referencing a 200 byte range of the temporary file.

(patch to be provided asap)
==============================================================