Ian Bicking has also seen it and commented. http://blog.ianbicking.org/2010/03/16/web-server-benchmarking-we-need/
He also comments about the need for a range of tests. Graham On 17 March 2010 09:37, Chris McDonough <[email protected]> wrote: > You might want to send this to reddit, Graham, if you don't want to put it > on the OP's website: > > http://www.reddit.com/r/Python/comments/be1q1/benchmark_of_python_web_servers/ > > - C > > > On 3/16/10 6:29 PM, Graham Dumpleton wrote: >> >> FYI. >> >> http://nichol.as/benchmark-of-python-web-servers >> >> The Apache/mod_wsgi configuration is quite amusing. >> >> They have used embedded mode, which is fine as can provide best >> performance, but they went all goofy on the Apache MPM configuration. >> >> <IfModule mpm_worker_module> >> ServerLimit 1 >> ThreadLimit 16000 >> StartServers 1 >> MaxClients 16000 >> MinSpareThreads 25 >> MaxSpareThreads 75 >> ThreadsPerChild 16000 >> MaxRequestsPerChild 0 >> </IfModule> >> >> CustomLog /dev/null combined >> ErrorLog /dev/null >> >> Having 16000 threads in one process is way over the top. Having that >> many will just blow out memory and even possibly make performance >> worse. They should have used the Apache default of 25 threads and >> ideally increased the number of processes rather than the number of >> threads in a single process. >> >> Although turning of access logging will help with performance, they >> should have turned it off completely instead of just sending it to >> /dev/null. By sending it to /dev/null it still has to perform the work >> of writing to the log, even if the data is thrown away. >> >> In a production system, if you really need to have access logging, >> would again suggest you turn it off, but use nginx in front of Apache >> and have nginx do the access logging instead. I have covered other >> reasons why nginx is good as a front end. In production though you >> shouldn't turn of error logging in Apache. >> >> As usual with benchmarks, one also has no idea of what the test >> application was doing. Where nearly all benchmark tests fail is that >> they test one specific use case. One needs to test a range of things >> including such things as varying sizes of request and response body >> content, speed of wsgi.file_wrapper and/or serving up files direct via >> WSGI, varying time in request handler, varying intensity of processing >> by handler and other things besides. In other words, real stuff and >> not things that never really happen in practice. >> >> So, first impressions are that this is just another benchmark that >> could just mislead people and create a whole new heard of sheep as >> people move to what they now perceive as the new leader. >> >> Graham >> > > > -- > Chris McDonough > Agendaless Consulting, Fredericksburg VA > The repoze.bfg Web Application Framework Book: http://bfg.repoze.org/book > > -- > 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.
