Tuesday, January 13, 2009

Coding Frisky (poorly)

A little while back I blog about a vision for a new type of web server to meet the needs of a new web. Along with how I thought it crazy how slow WSGI web servers are. FAWPS goal to be the fastest web server I think is a great niche. Frisky I want to be fast at runtime and at development time. Which seems to be why I am not going to dump all the code into the FAWPS contrib directory.
The itch is funny thing. If I am scratching the Frisky itch then I am not scratching the money making itch or the hiking itch. It has been hard to find the time to scratch the Frisky itch. I am looking for some Zen for balance so I can enjoy coding on Frisky and still keep everything else at bay.
Coding... Poorly
They nasty rat nest of code I have committed up to bitbucket frisky repository is very embarrassing. Which is only half the motivation for me to keep coding. The other half is the carrot of seeing stuff work! These two factors are probably the most highly motivating factors for me to continue to carve out time I don't have to work on it more. So I guess until I get the features in that I blogged about I will be coding poorly and not circle back to clean code up and write tests.
Today I was able to integrate features I had when Frisky was using FAWPS2 as the core webserver. That code has been sitting idle waiting for some features to get finished and today I decided to give it a wirl. Now src.hackingthought.com is using the new Frisky. hackingthought.com also forwards to blog.hackingthought.com. How about some more features:
  • Domain aliases (forwarding)
  • Static file serving (skipping WSGI application thus much faster)
  • Caching system
  • Compression system
  • Skeleton for mapping urls to WSGI applications
With all these new features performance hit was not noticable:
  • 762 bytes static file 1801.19 [#/sec] (mean)
  • 10 bytes cached and compressed 2197.04 [#/sec] (mean)
  • 74 bytes static file cached and compressed 2112.66 [#/sec] (mean)
Even with adding a lot of caching and path mapping code performance has not be effect much. Compared to FAPWS2 it is much slower, however this is a limit to asyncore python module that is platform independent and does not require any addtional libraries to be installed. I still plan on being able to hook into FAPWS3 once Frisky gets all the planned features in so there will be a configuration option to use FAPWS3. Enough work for one night.