2009/5/20 Michael Schurter <[email protected]>: > > On Tue, May 19, 2009 at 5:09 PM, gert <[email protected]> wrote: >> Ok you win, but only if you can show me wsgi code that can tell a >> request to go to a other process in case they are no more threads with >> some sort of ENV transfer session id :P > > Create a new thread. I'm sure transferring the ENV would take more resources. > > If you're out of threads per process on the OS level, I'm guessing you > have bigger problems than your choice of scaling techniques.
The number of threads in this case is the fixed number specified for 'threads' option to WSGIDaemonProcess. So, not exhausting OS level limit, just the limit on number of concurrent requests you allowed each daemon process. So, it is just a matter of properly sizing the number of threads per process to begin with to cope with expected number of concurrent requests. What this may need to be will depend on various factors, including how long requests take to be processed. Most of the time even a few threads will be sufficient for load most peoples applications get. People get carried away with trying to prematurely architect a system for some perfect storm of traffic. If they seriously are going to get huge traffic volumes, there are lots of other techniques they should be looking at. I dare not mention them though as then gert will believe he has to use them and so would have to endure more and more questions and don't have time at the moment. :-) Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
