Benchmarking Go and Python WEB servers

This is a creation in Article, where the information may have evolved or changed.

To build the Web applications I use mostlyPython. An year ago I started learningGo, mainly for fun. In the meantime it turned out that I had to rewrite some old CGI application written in C, which had worked withThttpdServer inChrootmode. I started searching for a tool with which I could write a standalone web application with embedded Web server, easy to CHR Oot. At the same time I started play withWeb.goFramework,Mustache.gotemplates, Go nativehttp Package andGomysqldatabase API. I found that the Go withhttp, Mustache.go andGomysqlpackages would be a ideal tools to do my job. So I decided-to-try write my application in Go.

during Work It appeared, I need something more flexible than  mustache.go  and something more mature and Bug-free than  gomysql . Finally, I wrote my application using kasia.go templates and mymysql  (I wrote these packages Specifically for my application and decided to make it available for Go community). Rewritten application works very well in production, even under much greater load than the previous one. I began to wonder on how faster (or maybe slower) are Go than Python for implementing standalone WEB applications. I decided to does several tests, taking into account the use of different frameworks and servers. For comparison, I picked up following Go packages:

• Raw Go http package,

• web.go Framework (it uses HTTP package to run in standalone mode),

• Twister Framework with its own HTTP server,

and following Python Web Servers/frameworks:

• web.py Framework with CherryPy WSGI server,

• web.py Framework with Gunicorn WSGI server,

• web.py Framework with gevent WSGI server,

• web.py Framework using Flup FastCGI to is a backend process for Nginx server,

• Tornado asynchronous Server/framework,

• tornado with Nginx as a load balancer.

For each case I wrote a simple application, slightly more complicated that typical Hello world example. Any application consist of:

• Parsing parameters in URL path using regular expressions,

• Using for statement to create multiple line output,

• Using printf-like formatting function/expression to format output.

• 
  

I think that these operations is common in any WEB application, so should is included in any simple benchmark test. Below I put links to the source code for all test applications:

• Go http

• Web.go

• Twister

• web.py

• Tornado

Testing environment

The test environment consisted of both PCs (traffic generator and application server) connected using direct Gigabitetherne T link.

• Generator: 2 x Xeon 2.6 GHz with hyperthreading, Debian SID, kernel:2.6.33.7.2-rt30-1-686 #1 SMP PREEMPT RT;

• Server: MSI Netbook with the core Intel U4100 1.30GHz, AC power connected, 64-bit Ubuntu 10.10, kernel:2.6.35-25 -generic #44-ubuntu SMP, Python 2.6.6-2ubuntu2, web.py 0.34-2, Flup 1.0.2-1, Tornado 0.2-1, Gunicorn 0.10.0-1, gevent 0.13 .0-1, Nginx 0.7.67-3ubuntu1 (config);

To generate HTTP traffic and measure the performance of any test application I used Siege Benchmarking utility. Siege can simulate multiple users using multiple threads. I use the following command to generate traffic:

Siege-c 200-t 20s http://ADDRESS:PORT/Hello/100

or multiple such commands with properly reduced- C parameter (in case I run multiple Python applications Sim ultaneously). It simulates traffic generated by the users and works for 20s. With given URL Web application produces, lines output for any request. Go applications was compiled using Go release.2011-02-01.1

Results

Gomaxprocs=1, one Python process:

gomaxprocs=2, both Python processes working simultaneously:

gomaxprocs=4, four Python processes working simultaneously:

Web.py+flup+nginx have worked with the following flup server options: multiplexed=false, Multithreaded=false. If Multiplexed=true It has worked slightly slower. Setting multithreaded=true doesn ' t improve performance and when there was only one process running the nginx server reports such errors:

[ERROR] 18166#0: *66139 connect () to Unix:/tmp/socket failed (11:resourcetemporarily unavailable) while connecting to UPS Tream

Multiple FastCGI processes were spawned using spawn-fcgi.

Conclusion

As you can see Go wins on almost all test cases. Worse results of web.go Framework is probably due to the fact that it's try find static file for given URL before R Un a handler function. It surprised me the very high performance of the Tornado framework. I was also surprised, which cherrypy server is faster than Nginx+flup (I use web.py+flup+nginx F Or almost all my Python Web applications).