[Web-SIG] wsgi and generators (was Re: WSGI and start_response)

[Manlio Perillo]

P.J. Eby ha scritto:
> At 02:04 PM 4/10/2010 +0100, Chris Dent wrote:
>> I realize I'm able to build up a complete string or yield via a
>> generator, or a whole bunch of various ways to accomplish things
>> (which is part of why I like WSGI: that content is just an iterator,
>> that's a good thing) so I'm not looking for a statement of what is or
>> isn't possible, but rather opinions. Why is yielding lots of moderately
>> sized strings *very bad*? Why is it _not_ very bad (as presumably
>> others think)?
> 
> How bad it is depends a lot on the specific middleware, server
> architecture, OS, and what else is running on the machine.  The more
> layers of architecture you have, the worse the overhead is going to be.
> 
> The main reason, though, is that alternating control between your app
> and the server means increased request lifetime and worsened average
> request completion latency.
> 

This is not completely true.
At least this is not how things will work on an asynchronous WSGI
implementation.

It is true that alternating control between your app and server decrease
performance.
This can be verified with:
http://bitbucket.org/mperillo/txwsgi/src/tip/doc/examples/demo_cooperative.py

However yielding small strings in the application iterator, because the
application does not want to buffer data, will usually not cause the
problems you describe.

Instead, the possible performance problems have been described by Graham.


Moreover, when we speak about latency, we should also consider that web
page are usually served to human users.
In this case, latency is not the only factor to consider.

Is it better for the user to wait 3 seconds for some text to appear on
the browser window, and then wait for other 5 seconds for the complete
page to be rendered, or having to wait 5 seconds for some text to appear
on the browser window?

> [...]
> If you translate this to the architecture of a web application, where
> the "work" is the server serving up bytes produced by the application,
> then you will see that if the application serves up small chunks, the
> web server is effectively forced to multitask, and keep more application
> instances simultaneously running, with lowered latency, increased memory
> usage, etc.
> 

Yielding small strings *will* not force multitasking.
This can be verified with:
http://bitbucket.org/mperillo/txwsgi/src/tip/doc/examples/demo_producer.py

WSGI application will be suspended *only* when data can not be sent to
the OS socket buffer.

Yielding several small strings will *usually* not cause socket buffer
overflow, unless the client is very slow at reading data.

Instead, ironically, you will have a problem when the application yields
several big strings.

In this case it is better to yield only one very big string, but this is
not always feasible.
And I'm not sure if it is worse to keep a very big buffer in memory, or
to send several not small chunks to the client.

> [...]


Regards  Manlio