On 5 May 2010 10:07, Jason Garber <[email protected]> wrote: > And by the way, how long do your requests take? That is a huge factor in > how many threads you should have. If they are out the door in 20ms, then > you don't likely need many threads. If they are taking 2 seconds and you > are not using nginx (well, you have larger problems at that point), then you > will need more threads to handle any load.
If your requests are taking 2 seconds because of processing time in the request handler, you have problems regardless of whether nginx is used. Using nginx in front can help a little bit to avoid issues with uploads when you have a slow client, but the default buffer size in nginx is only 1MB, so for large uploads it doesn't help too much, as above that and it will start streaming again which means Apache still tied up. If you are having to support lots of large uploads in parallel with each taking a long time you perhaps want to handle the upload outside of your core Python web application some how. There are various things one might look at for that. Slow downloads can also be a problem. To avoid that, one way is to use something like X-Accel-Redirect header that nginx front end understands such that Python web application just sets the header and nginx actually serves the file. The problem is that many don't understand that blocking WSGI isn't the best solution for everything. This is especially the case from long running requests. This is why upload/download accelerators or asynchronous Python web servers can be better. Just shifting everything to the latter isn't necessarily a good idea either and a mix of technologies is required. The problem that generates though is issues with handling authentication/authorisation seamlessly across both. Anyway, as Jason points out, the key thing is how long your requests take. If you have lots of long running requests you have to start increasing processes/threads, if requests are handled quickly, even a small number of processes/threads can quite happily handle a large number of requests. This is why focusing on improving the response time of your application is more important than most other things. You see lots of people thinking they will solve their problems by finding what appears to be the fastest web server, that is just plain rubbish and ultimately will make no difference as that isn't where the bottlenecks are. So, look at database query times and improving them. Look at caching, be that in the application using memcached or in front end web server caches. Do everything possible to avoid doing the stuff that takes a long time and you will get a much better results as far as request capacity. Graham > On Tue, May 4, 2010 at 8:05 PM, Jason Garber <[email protected]> wrote: >> >> Generally speaking, you need to think of concurrency. At most, your WSGI >> setup will not be able to handle more concurrent requests than it has >> threads to handle them. This will also depend on your use of nginx as a >> proxy, because it buffers requests and responses to a degree, thus freeing >> up python threads quickly to be used for other requests. >> Other considerations include how many database connections do you *really* >> want open at once? >> Ultimately, if you are just getting started, then use a sensible default >> (eg 1-2 process with 5-10 threads), and see how it copes. >> For more information, search this mailing list extensively, because this >> has been hashed, rehashed, and rerehashed many times here. >> Thanks! >> Jason Garber >> On Tue, May 4, 2010 at 10:55 AM, Boris Schaeling <[email protected]> >> wrote: >>> >>> Are there any guidelines how to find a reasonable value for processes and >>> threads in daemon mode? For example how do I know if x processes and y >>> threads are sufficient? >>> >>> <http://code.google.com/p/modwsgi/wiki/ProcessesAndThreading> recommends >>> to "plan ahead and make sure the number of processes and threads defined is >>> adequate to cope with the expected load". Now a simple to interpret number >>> like "mod_wsgi load average" would be great. :) As it doesn't exist are >>> there any mod_wsgi-specific guidelines out there to calculate such a number >>> yourself? >>> >>> Boris >>> >>> -- >>> 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. >>> >> > > -- > 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. > -- 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.
