Sunday, March 29, 2009

Hacking Frisky Round 3

Progress is fun
Progress continues (finally) on Frisky (async web server I started hacking on for fun). As previous post mentioned my initial progress I have finally taken a second step. Thanks to zenhabits I have been starting to be very productive with my time. I decided to get back to seeing if I could continue with my original vision of creating a new kind of webserver. As I review my vision I realize core is a concept of stablity and performance. Adding multiprocessor support was critical because it would impact almost all the other features and almost all the code. So I had to face the hurdle and jump.
Punching Performance in the eye
Python 2.5 with processing installed is not down to ~470 req/sec compared to ~ 1,000 rec/sec for WSGI requests. Currently the bottle neck is IPC from the main process to the processes running the WSGI code. Let some of the reason I am not going to nix processes:
  • As this is the first web server (for that matter any server that needed performance) and it is pre alpha code it should get faster with TLC
  • Caching support is not available once it is fixed that should greatly increase cacheable requests
  • IPC is probably not the best way to pass information back and forth between processes but it sure is easy with the multiprocessing module!

Truthfully most requests that are not cached are waiting on database or IO and 500 req/sec would be good. Since static file performance is not affected and once I fix the caching code that will be as fast as static files in the short term I am not going to worry about the slowness.

Making coding easier
As I mentioned before I wanted to get the multiprocessing done so I could support some other features. One of those is hot deployment of code and in development an autoreload feature. Basically they are one in the same. By the server creating a new process it will get the new code. This could be done at runtime in production or during development to just load a new process when a file modification is noticed in the code base.

Next please
Worker processes was one of the other really innovative features I wanted Frisky to have. This is important because it will allow me to go back and start fill in lots of missing pieces like configuration, test suite and framework integrations (TurboGears, Django, Pylons ect).

PS. Code is on bitbucket http://bitbucket.org/lateefj/frisky/overview/