While fixing the dishwasher last year by flushing out bits of garbage, I realized the dishwasher had a built-in lawn sprinkler.
The duct tape worked remarkably well.
While fixing the dishwasher last year by flushing out bits of garbage, I realized the dishwasher had a built-in lawn sprinkler.
The duct tape worked remarkably well.
I have been planning to compare mod_wsgi with paste.httpserver, which Zope 3 uses by default. I guessed the improvement would be small since parsing HTTP isn’t exactly computationally intensive. Today I finally had a good chance to perform the test on a new linode virtual host.
The difference blew me away. I couldn’t believe it at first, so I double-checked everything. The results came out about the same every time, though:
I used the ab command to run this test, like so:
ab -n 1000 -c 8 http://localhost/
The requests are directed at a simple Zope page template with no dynamic content (yet), but the Zope publisher, security, and component architecture are all deeply involved. The Paste HTTP server handles up to 276 requests per second, while a simple configuration of mod_wsgi handles up to 1476 per second. Apparently, Graham‘s beautiful Apache module is over 5 times as fast for this workload. Amazing!
Well, admittedly, no… it’s not actually amazing. I ran this test on a Xen guest that has access to 4 cores. I configured mod_wsgi to run 4 processes, each with 1 thread. This mod_wsgi configuration has no lock contention. The Paste HTTP server lets you run multiple threads, but not multiple processes, leading to enormous contention for Python’s global interpreter lock. The Paste HTTP server is easier to get running, but it’s clearly not intended to compete with the likes of mod_wsgi for production use.
I confirmed this explanation by running “ab -n 1000 -c 1 http://localhost/”; in this case, both servers handled just under 400 requests per second. Clearly, running multiple processes is a much better idea than running multiple threads, and with mod_wsgi, running multiple processes is now easy. My instance of Zope 3 is running RelStorage 1.1.3 on MySQL. (This also confirms that the MySQL connector in RelStorage can poll the database at least 1476 times per second. That’s good to know, although even higher speeds should be attainable by enabling the memcached integration.)
I mostly followed the repoze.grok on mod_wsgi tutorial, except that I used zopeproject instead of Repoze or Grok. The key ingredient is the WSGI script that hits my Zope application to handle requests. Here is my WSGI script (sanitized):
# set up sys.path. code = open('/opt/myapp/bin/myapp-ctl').read() exec code # load the app from paste.deploy import loadapp zope_app = loadapp('config:/opt/myapp/deploy.ini') def application(environ, start_response): # translate the path path = environ['PATH_INFO'] host = environ['SERVER_NAME'] port = environ['SERVER_PORT'] scheme = environ['wsgi.url_scheme'] environ['PATH_INFO'] = ( '/myapp/++vh++%s:%s:%s/++%s' % (scheme, host, port, path)) # call Zope return zope_app(environ, start_response)
This script is mostly trivial, except that it modifies the PATH_INFO variable to map the root URL to a folder inside Zope. I’m sure the same path translation is possible with Apache rewrite rules, but this way is easier, I think.
Last time I ran the RelStorage performance tests, the write speed to a MySQL database appeared to be slow and getting slower. I suspected, however, that all I needed to do was tune the database. Today I changed some InnoDB configuration parameters from the defaults. The simple changes solved the MySQL performance problem completely.
The new 10K chart, using RelStorage 1.1.3 on Debian Sid with Python 2.4 and the same hardware as before:
I added the following lines to my.cnf to get this speed:
innodb_data_file_path = ibdata1:10M:autoextend innodb_buffer_pool_size=256M innodb_additional_mem_pool_size=20M innodb_log_file_size=64M innodb_log_buffer_size=8M innodb_flush_log_at_trx_commit=1 innodb_file_per_table
This is similar to the configuration suggested by the InnoDB documentation for a 512 MB database server. Even if you have a 16 GB server, I would suggest starting with the settings for a 512 MB server, then watch what happens to the RAM and CPU on the database server when you connect all of your client machines simultaneously. You want to leave at least half the RAM available for disk cache and usage spikes.
Not all of these changes are related to speed. The innodb_file_per_table option just seems like a good idea because it makes tables visible on the filesystem, which should improve manageability. I think it might improve cache locality as well.
With these changes to my.cnf, ZEO, PostgreSQL, and MySQL all perform about the same for writes, with MySQL having a slight lead. I suspect all three are hitting hardware and kernel limits. I think the differences would be more pronounced on higher-end storage hardware.
A big caveat: It’s risky to change InnoDB settings unless you’re familiar with all the effects. Some changes break compatibility with existing table data. Get to know the InnoDB documentation very well before you change these settings, and make backups using mysqldump, as always.
Meanwhile, Oracle XE continues to write slowly and ZEO read performance is so bad that it’s off the chart. I bet ZEO read performance could be improved with some simple optimizations somewhere, but I don’t have an incentive to fix that. 🙂 Perhaps it has been fixed in ZODB 3.9.
I am more than happy to support RelStorage as best I can by email. Every time I do, however, I always get a nagging feeling that I could help RelStorage users a lot better if we set up a short term support contract. I would very much appreciate a chance to optimize their system by testing the performance of different configurations. When the communication is limited to email, neither of us gets a chance to discover how we might help each other better.
So if you’re a RelStorage user and your database is growing by tens of gigabytes, please seriously consider a short term support contract with my little company. A little tuning or code revision in the right place could yield orders of magnitude performance gains. I really want to help you directly. Contact me at shane (at) willowrise (dot) com.