[Web-SIG] Server-side async API implementation sketches

[James Y Knight]

On Jan 10, 2011, at 4:48 AM, chris.dent at gmail.com wrote:

> My reaction too. I've read this elsewhere on this list too, in other
> topics. A general statement that the correct way to make an
> efficient WSGI (1) app is to return just one body string.
> 
> This runs contrary to everything I've ever understood about making
> web apps that appear performant to the user: get the first byte out to
> the browser as soon as possible.

Weellll. You want to get the earliest byte *which is required to display the page* out as soon as possible. The browser usually has to parse a whole lot of the response before it starts displaying anything useful.

And in order to do that, you really want to minimize the number of round-trip-times, which is heavily dependent upon the number of packets sent (not the amount of data!), when the data is small. Using a generator in WSGI forces the server to push out partial data as soon as possible, so it could end up using many more packets than if you buffered everything and sent it at once, and thus, will be slower.

As the buffering and streaming section of WSGI1 already says...:
> Generally speaking, applications will achieve the best throughput by buffering their (modestly-sized) output and sending it all at once. This is a common approach in existing frameworks such as Zope: the output is buffered in a StringIO or similar object, then transmitted all at once, along with the response headers.
> 
> [...]
> 
> For large files, however, or for specialized uses of HTTP streaming (such as multipart "server push"), an application may need to provide output in smaller blocks (e.g. to avoid loading a large file into memory). It's also sometimes the case that part of a response may be time-consuming to produce, but it would be useful to send ahead the portion of the response that precedes it.

James