the law of averages

First session of the day was on Scaling Python on the Web; rough notes which I may clean up later:

• How fast is fast enough?
  • Don’t prematurely optimize
• Know where the bottlenecks are, and optimize those specifically?
• Orders of magnitude: static (httpd), dynamic (python), db-queried
• Even 40 req/s in 3.4m pages/day
• Hundreds to low thousands of dynamic page views is usually good enough
• Scaling isn’t about the language, it’s about:
  • DRY: cache!
• share nothing
• built a sample photo-app, FlickrKillr, for demonstration purposes
• preloaded with 100k’s users, 10-20 photos each
• first iteration: CGI
• roughly 23 requests/second
• problems:
  • loading Python interpreter for each request
• all resources initialized for each request (inc. db connection)
• possible remedies:
• run a Python web server (long-running process)
• make one db connection per thread instead of request
• other remedies:
• fastcgi
• snakelets, twisted.web, RhubarbTart
• mod_python
• second iteration: python app server (CherryPy used for this demo)
  • roughly 139 requests per second
  • problems
    • global interpreter lock—can only utilize one core on a dual core machine
  • sessions in the database—prefer an in-memory session store
  • remedies:
  • run multiple instances of CherryPy (overcode GIL)
  • but then we need to balance with something like nginx
  • other options
• cherrypy in mod_python
• version 3: load balancing with nginx
  • 217 requests/sec
  • outstanding problems
    • static files read from disk every time
  • and they’re being read/written from python
  • solutions:
  • memcached
• combine with memcached w/ nginx
• version 4: caching
  • 616 req/sec (benchmarking w/ homegrown tool)
• 1750 req/sec (benchmarking w/ ab)
• other notes:
• don’t forget to index

• without an index, the fourth iteration falls down to 28 requests/sec

  http://www.polimetrix.com/pycon/demo.tar.gz