WSGI server benchmarks.

10 views
Skip to first unread message

Graham Dumpleton

unread,
Mar 16, 2010, 6:29:50 PM3/16/10
to modwsgi
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

unread,
Mar 16, 2010, 6:37:09 PM3/16/10
to mod...@googlegroups.com
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


--
Chris McDonough
Agendaless Consulting, Fredericksburg VA
The repoze.bfg Web Application Framework Book: http://bfg.repoze.org/book

Graham Dumpleton

unread,
Mar 16, 2010, 7:35:04 PM3/16/10
to mod...@googlegroups.com
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

> --
> You received this message because you are subscribed to the Google Groups
> "modwsgi" group.
> To post to this group, send email to mod...@googlegroups.com.
> To unsubscribe from this group, send email to
> modwsgi+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/modwsgi?hl=en.
>
>

cd34

unread,
Mar 16, 2010, 7:42:02 PM3/16/10
to modwsgi
There are so many problems with those benchmarks that one doesn't know
where to start. Dubious data collection methods, configuration
errors, testing non-production configurations, etc. He spent a lot of
time collecting the data, it is presented well, but, the conclusions
drawn from poorly collected data just make a mess for those that have
to clean up after someone uses that information to base their startup
deployment.

Pity that it keeps getting upvoted.

Pretty graphs mesmerize the typical reader.

Reply all
Reply to author
Forward
0 new messages