[pylons-discuss] some waitress design questions

[Jonathan Vanasco]

does anyone know if the workers in waitress are spawned as-needed for each
request, or if they are pre-spawned and answer requests when available?

I think it is the latter. if so, is there a reasonable chance of having a
max-requests feature implemented (or would this be possible to kludge
together myself for local testing)?

i'm trying to recreate some issues that are appearing on other wsgi
containers to debug within waitress, and am having a hard time. I think
the problem is happening due to how the worker processes are launched.

[Bert JW Regeer]

The threads that run the WSGI app are pre-spawned, they wait on a new request to be added to a queue, peel one off, pass it down the WSGI app, and then back.

There are no other "workers". The rest is a simple asyncore loop, whereby requests are accepted, and added to the list of sockets to listen on. Responses are sent back out when asyncore signals that the socket is ready for writing. These are called "channels" in waitress. You can already limit the amount of channels (open connections). Do note that a channel does not explicitly map to a single request (i.e. with HTTP pipelining it could be multiple) and an open connection does not imply that there is an active request (and thus thread that is processing said request) because of HTTP keep-alive.

Look at:

--connection-limit
--cleanup-interval
--channel-timeout

For tuneables that affect how many connections can be open at once, how often waitress cleans up inactive channels and what the maximum time is to allow for HTTP keep-alive requests.

What are you trying to do with a "max requests"?

What issues?

does anyone know if the workers in waitress are spawned as-needed for each request, or if they are pre-spawned and answer requests when available?
I think it is the latter. if so, is there a reasonable chance of having a max-requests feature implemented (or would this be possible to kludge together myself for local testing)?
i'm trying to recreate some issues that are appearing on other wsgi containers to debug within waitress, and am having a hard time. I think the problem is happening due to how the worker processes are launched.
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/905cf706-6ac6-4a7b-8afc-1381c2f7623e%40googlegroups.com <https://groups.google.com/d/msgid/pylons-discuss/905cf706-6ac6-4a7b-8afc-1381c2f7623e%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Jonathan Vanasco]

Post by Bert JW Regeer
The threads that run the WSGI app are pre-spawned, they wait on a new
request to be added to a queue, peel one off, pass it down the WSGI app,
and then back.
...
What are you trying to do with a "max requests"?

Thanks for all the above. It answers all my questions about how waitress
works.

Several web servers implement a concept of "max number of cumulative
requests each subprocess can serve" before that subprocess (thread or fork)
is terminated and replaced with a new process.

The situation I'm trying to debug has to do with some unpredicted behavior
and a particular 'constant' variable that is assigned during the
application initialization, and (should only be) read afterwards. It works
fine initially, then seems to 'unset' to a default value after an hour or
so. I want to ensure the error isn't being triggered when 'max requests'
is hit and a new subprocess being spawned.

I don't think it is, but I'd like to be sure. It's been a pain trying to
recreate this scenario with uwsgi/nginx and apache/mod_wsgi.

[Bert JW Regeer]

Post by Bert JW Regeer
The threads that run the WSGI app are pre-spawned, they wait on a new request to be added to a queue, peel one off, pass it down the WSGI app, and then back.
...
What are you trying to do with a "max requests"?
Thanks for all the above. It answers all my questions about how waitress works.
Several web servers implement a concept of "max number of cumulative requests each subprocess can serve" before that subprocess (thread or fork) is terminated and replaced with a new process.
The situation I'm trying to debug has to do with some unpredicted behavior and a particular 'constant' variable that is assigned during the application initialization, and (should only be) read afterwards. It works fine initially, then seems to 'unset' to a default value after an hour or so. I want to ensure the error isn't being triggered when 'max requests' is hit and a new subprocess being spawned.

If it is a forking() server, I would think they create the WSGI app once, and then upon forking the children just use that same one rather than re-initialise the whole WSGI app for each child it forks, but I may be wrong.

Either way, I don't see how after an hour it would suddenly become unset, because either it forks from the original, and re-uses, in which case it should be initialised, or it re-initialises the whole WSGI app from scratch, at which point it should be set to the non-default.

Post by Bert JW Regeer
I don't think it is, but I'd like to be sure. It's been a pain trying to recreate this scenario with uwsgi/nginx and apache/mod_wsgi.
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/0d72eb02-4ef8-4f27-8e9a-616db185156b%40googlegroups.com <https://groups.google.com/d/msgid/pylons-discuss/0d72eb02-4ef8-4f27-8e9a-616db185156b%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.