Hacker News Reader

Comment by n8agrin | Hacker News Reader

Awesome to see more Python webservers coming to light, and fast ones at that. One observation though; anyone else notice that the bar chart is a bit misleading? It compares running Tornado in 4 processes behind nginx to running Django behind Apache and Cherrypy as a single Python process. As a fellow coworker put it, "With 4 extra processes running of course it will be 4 times as fast." I'm not opposed to this kind of comparison when the intent is to show how configurations can increase req/sec, but if the intent is to compare one Pythonic webserver to another, this comparison seems a bit unfair. That said, assuming the "Tornado (1 single-threaded frontend)" measure is simply Tornado running as a single Python process, it still is plenty faster than Cherrypy.

View on HN

Apache/mod_wsgi creates multiple processes (or can). The issue is that Facebook didn't tell us what configuration settings they used. Did they limit the number of processes? Did they not have it start up enough at the start?

It's clear that Facebook wasn't using a single Apache/mod_wsgi process because that wouldn't get close to 2,000 requests per second. I'm sure they gave it the number of processes that were appropriate for the amount of RAM on the box - the issue is that every Apache process (of which I'm sure they dozens if not hundreds) uses up memory.

It's hard to set that up properly and that's what makes benchmarking so hard. Still, it's not hard to believe that with the weight of Apache in the process, there's going to be at least 5MB of overhead for every request. If you were saving that 5MB of RAM per client times the 2,223 requests per second, that's 11GB worth of freed RAM per second. Let's say Django uses 10MB of RAM for a request: that's an extra 50% increase in capacity right there just by eliminating the 5MB Apache process overhead. And Apache tends to be on the heavier side (5MB is somewhat low as an estimate) and if you can do it asynchronously, you're not tying up RAM as you wait for clients, so you do well.

Now, put Apache/mod_wsgi behind nginx (as a proxy) and you'll also see an increase in requests per second because you won't be tying up all that RAM as a client is downloading and only use the RAM while actually doing work in Python freeing that memory to be used elsewhere. However, I'm guessing that they ran this benchmark locally and so the network tying up Apache instances wasn't a factor.

Clearly, benchmarks are benchmarks, but it isn't as if Facebook and FriendFeed don't have lots of smart engineers and they wouldn't be using their own server if Apache was significantly better. They have a site of massive scale and know how to benchmark things since you need objective data to make decisions based on rather than the religious arguments some get into.

I'd guess that, if one could get Django running under Tornado, it would run similarly and that it's more of Apache being the bottleneck/RAM hog.

and the way they handle request in non-blocking way still have many benefits over Django in real web application especially if you have to make many calls to "other" http server to fetch data which happens a lot in today's world.

But if you're going to put nginx in front of it, why bother with Apache at all?

IApache's only saving grace is that you can handle everything monolithically (albeit with mediocrity).

CherryPy is multi-threaded, so I am not sure what you are saying is correct. There are two types of servers: multi-threaded, multi-process. Tornado is multi-process. If your server is multi-threaded, it uses all of the cores without additional processes.

CherryPy did max out the CPU on all of the cores in the load test, so I think it was a fair test.

If you ran a single CherryPy instance, I don't see how that is possible. The Python global interpreter lock prevents a single process from making use of multiple cores.

No, it doesn't. I/O bound tasks can heavily use multiple cores just fine using threads.

If you're CPU bound in pure-python computations then the GIL (Global Interpreter Lock) will cause you to only make use of one core. This is intentional: threads are hard, processes are simple.

I know that, except most web application servers spend most of their time in I/O - socket, database, etc. Threads are not hard: wanton abuse of shared state and concurrent modification of the shared state is hard to get right; tread a threaded app like a message-passing app and you have a much simpler life.

I'm intimately familiar with the limitations of python threads - and right now I'm the maintainer of the multiprocessing module, which is the process-based "reply" to the stdlib threading module.

<3 multiprocessing, <3 you.

I wasn't trying to claim you don't understand python, simply that the only way to be CPU bound on multiple cores with a single python process (as is claimed) is to be running non-pure python code that unlocks the GIL before doing CPU intensive work.

Can python use mutiple cpus/cores with threads? Short answer no. Long answer, yes for some things.

Even cpu bound tasks can release the GIL to do processing(for non python api tasks).

Likewise, 4 extra processes does not mean 4 times as fast if you only have one or two cores on your machine. Check out the details at http://www.tornadoweb.org/documentation#performance for how we ran the test.

Reply on news.ycombinator.com