
Python vs. Node vs. PyPy benchmarks - chanux
http://blog.kgriffs.com/2012/11/13/python-vs-node-vs-pypy-benchmarks.html
======
jdub
Don't miss this follow-up post, though:

[http://blog.kgriffs.com/2012/12/18/uwsgi-vs-gunicorn-vs-
node...](http://blog.kgriffs.com/2012/12/18/uwsgi-vs-gunicorn-vs-node-
benchmarks.html)

~~~
davyjones
Graph 3 as a log y chart would've been nice.

------
wyuenho
I'm actually quite perplexed as to why the blog author chose to use the
WSGIRef which is known to be one of the slowest of the bunch according to this
much more thorough benchmark:

<http://nichol.as/benchmark-of-python-web-servers>

Even more perplexed, why wasn't the payload and the WSGI apps sources
published?

~~~
robert-zaremba
Your observation is good. Author should clarify this. But in his next articles
he shows benchmark against other web frameworks, which shows more justified
results

~~~
fijal
That doesn't really answer why use the slowest one with PyPy (and no, uWSGI
does not work for PyPy, but a lot of stuff does)

~~~
unbit
uWSGI works with PyPY (Obviously with lot of limitations on the features).
<http://projects.unbit.it/uwsgi/wiki/PyPy> The problem is that for the vast
majority of the webapps there is (still) no advantage. I only wanted to focus
on that as i have invested days on (really complex for me) pypy sources, and i
do not want people to ignore it ;)

------
calpaterson
I don't understand why there are no numbers on these graphs. Graphs are pretty
pointless if you don't label the axes.

~~~
rplnt
It's either fixed or there's a problem on your end.

~~~
oib
Nope, I don't get any numbers/labels either. Seems like the website is
incompatible with a bunch of browsers.

~~~
bhauer
He's just using Flot, which a lot of us use for canvas-based charts. Do they
work for you at all?

<http://www.flotcharts.org/>

If not, what browser are you using? It would be nice to know if Flot is not
compatible with something.

~~~
oib
iceweasel 10.0.12 (basically the same as Firefox 10.0.12) It ships as the
default browser for debian wheezy. The home page of flotcharts.org does work
correctly.

I also tried Konqueror Version 4.8.4 (KDE's browser) and it didn't even
display the graphs (not in the blog post or on flotcharts.org).

------
wheaties
This whole test says more to me about the performance of non-blocking MongoDB
drivers than it says about the underlying performance of the
frameworks/languages. The python tests lacked a non-blocking driver. Why not
use the PostGRES drivers ? That would give a much more accurate and fair
treatment.

And for the record, I don't care one way or the other which is "faster," just
make a damned test where one isn't given such a clear leg up.

------
rdtsc
Another set of benchmarks that shows Erlang's cowboy coming ahead on EC
instances. It also compares EC2 vs real hardware and throws more contenders in
the mix.

On physical hardware the race is pretty close (except node, python-gevent, but
cluster node did very well).

[http://eric.themoritzfamily.com/websocket-demo-
results-v2.ht...](http://eric.themoritzfamily.com/websocket-demo-
results-v2.html)

~~~
ericmoritz
Yeah, because of cowboy and Erlang's design it is going to out perform a
single process evented server hands-down.

    
    
      1. The evented servers are bound to one CPU, Erlang will use all CPUs 
      2. any bit of blocking code will stall the other code, even it just for a moment.
    

It is a little unfair to compare the two approaches.

~~~
rdtsc
I am not sure it will always under-perform with one CPU. It depends if async
threads are used and if kernel poll is enabled. Erlang is designed for better
low latency response at the expense of _some_ sequential slow down. I wonder
if Erlang would scale slower but it will throw less errors as number of
requests increases.

EDIT:

Also it would seem benchmarking Erlang and forcing it to run on a single core
just like node.js is deliberately handicapping it. One of the strengths of
Erlang is exactly the ability to take advantage of multiple cores.

------
justin_vanw
Things like this DO NOT MATTER.

Facebook was built on PHP and MySQL, both of which are awful pieces of crap.

Twitter went down like every week for a year. It was written on RoR by people
who didn't really know RoR.

Meanwhile, a bunch of better engineers using better technology got their
clocks cleaned while the winners eventually had so much money they could
afford to hire an army of engineers to rewrite everything.

If you know Javascript really well, use Node (although I feel sorry for you).
If you know Python really well, use Python (yay). If you don't know anything,
well, pick something. If you are choosing a programming language because of
how many QPS you can get on some trivial task, you are an idiot.

You know the graph I would like to see? A scatterplot of how good various
startup founders and early team were on engineering vs finding a market fit,
with the dots labeled with how rich they are now.

------
Yaggo
Just FYI, in my own tests I've found Node.js performing about 50% better
(req/s) than Tornado/C-python, while Tornado/pypy comes very close to Node.js'
performance. Tornado is one of the fastest Python web frameworks and does not
use WSGI (by default).

The point is that pypy can crunch almost as fast as Node.js, so while Node.js
may set the standard, Python is not bad choice either from performance
perspective.

------
guilloche
I am surprised that node.js performs significantly better than python & pypy.
Can anyone have some explanation?

~~~
raphman
It depends on the web framework. As the author of the benchmark shows in a
later blog post [1], Python+uWSGI can be faster than Node.js

[1] [http://blog.kgriffs.com/2012/12/18/uwsgi-vs-gunicorn-vs-
node...](http://blog.kgriffs.com/2012/12/18/uwsgi-vs-gunicorn-vs-node-
benchmarks.html) (link originally posted by jdub in this discussion)

------
Egregore
For Node.js it's a big difference between 1k and 64k files, what about
something in between, like 32k files?

------
ricardobeat
Red and green side-by-side on a chart... noo :(

<http://jfly.iam.u-tokyo.ac.jp/color/#pallet>

<http://tools.medialab.sciences-po.fr/iwanthue/>

~~~
swah
IMO its a little bit excessive to ask that every graph generated is color-
blind safe...

Isn't there software for colorblind people to correct that? (Something that
changes the palette of colors displayed...)

~~~
ricardobeat
Red & green is the stereotypical colorblind test, that's a pretty obvious
combination to avoid. It's easy to choose colors that are at right angles in
the color wheel, and that's not how accessibility works - you can't require
every paraplegic to have a special wheelchair that can climb stairs, despite
it existing...

------
mercuryrising
Where's the source code? I'd like to see how long it takes someone who doesn't
know either language to figure out what's happening in the code (a 'new' kind
of response time).

------
est
If you are using wsgiref don't forget the patch

    
    
        __import__('BaseHTTPServer').BaseHTTPRequestHandler.address_string = lambda x:x.client_address[0]

------
swah
I'd love to see something on the JVM against this.

------
phenom
Edit: pointed out in other comment

------
tferris
Node/V8 is a beast and will dominate web development in few years.

EDIT: Downvote me, I don't care.

~~~
pestaa
If the web development industry moves from PHP to JavaScript as the main
backend language... well, from quality perspective nothing will change. IMO.

~~~
espadrine
If one company gave you a PHP job, and another a JS backend job, and that'd be
all you got, would you flip a coin to pick one?

Or is this a way to say that you feel more satisfied with your work in Python
than with your work in node?

~~~
pestaa
This is my way to say several points:

\- If the majority of our industry can make the switch to JavaScript, they'll
ruin it in terms of average code quality.

\- Even good, idiomatic JavaScript code sucks for reasons inherent in the
language.

\- I wish people wrote just good enough Python or Erlang or Haskell or
whatever code instead of excellent PHP/JavaScript.

So yes, I treat PHP and JavaScript backend jobs equally.

[Edit: grammar.]

~~~
tferris
JS is a modern and beautiful language, comparing it with PHP is bold. People
fighting Node are just afraid to change and to start from zero again, they
fear the truth.

No other language offers C-class speed, that rich ecosystem (which is fully
async) paired with such an easy approachability plus the best and most modern
package manager around. Speed is not everything but users won't tolerate
unresponsive web services based on sluggish language implementations and
cumbersome frameworks anymore, it's not 2005.

Why do you think did Airbnb, LinkedIn and many more choose Node in production
for high traffic apps?

Don't get me wrong, Python, Erlang, Haskell are great languages, I love them
all but since V8/CrankshaftJIT/Node, JS is playing in a different league with
an amazing cost-benefit ratio and I am confused by people ignoring this
(however, I see rather Go and Clojure as real contenders to JS since they
offer modern language concepts too paired with speed and real concurrency but
they are again compiled and deploying JVM based stuff (Clojure) is no fun at
all).

~~~
rlander
> deploying JVM based stuff (Clojure) is no fun at all).

In what world is typing "lein uberjar" and moving the resulting file to your
webserver considered hard?

