Documentation · Programming · Summer of Code 2007

Abyss and Nginx now documented and working

Abyss and Nginx have been both been successfully tested (but not without some minor bug fixes in fastcgi-mono-server). I’m not sure how big of news this is, as I never heard of these servers until I found them in a table on Wikipedia, but apparently Nginx is big in Russia.Docs are at the usual place, and I’ve added an extra notice about the potential security risks of using ASP.NET by extensions alone. (Thanks to Daniel Nauck for pointing it out.)

Important changes that make this possible:

  • Status 200 is sent again. Abyss was sending its own status (I presume 404) if the file didn’t exist and fastcgi-mono-server wasn’t sending in information.
  • Blocking is no longer set for sockets. It didn’t appear to provide any essential features, as the server uses asynchronous calls anyway, but it was causing the unmanaged socket to stop listening on Abyss.
  • Response headers are now stored in a string builder and sent only once the server has finished outputting them. The fast onslaught of tiny requests was causing occasional failure in Nginx.

If you use either of these server, please test them out and let me know of any issues you might encounter.

Sincerely,
Brian Nickel

3 thoughts on “Abyss and Nginx now documented and working

  1. This is good news. While Abyss is not terribly popular, it is a solid and easy to configure web server that is cross platform. By making the Mono fastCGI server compatible, you have opened up yet another useful way to use the Mono framework for web development. Thank you.

  2. Hi Brian,

    Awesome work on this project, I have an interesting system that I would like to implement using your fastcgi server but I’m not sure if what I need is possible. I would like to use lighttpd to host thumbnails / photos on my mono driven website.

    All the user uploaded imagery is stored on a mogile FS server (an OS distributed storage service), and I have standard naming convention for these files ( /storage/{member key}/{file key}.{jpg/gif/png}). Now the trick is that i want to serve direct from disk if the requested file is there (allow the default static handler to operate).

    BUT… if its not on the local disk, then I need to handle the request though mono to fetch the file from mogile FS, stream it to the client and store it on the disk so that subsequent requests grab that file straight off the disk.

    I’m assuming I could do something like this with a HTTP module, where I can catch the application exception generated by a file-not-found error, clear the response and do my magic instead. What do you think? am I dreaming?

    Is pushing images through the asp.net static file handler a bad idea? much slower than lighttpd serving static files itself?

    Cheers!
    Mike

  3. Mike,

    Pushing files through the FastCGI static file handler will probably add some overhead, but I don’t think it’s a terrible idea.

    An 11 year old article gives this formula for rates:
    Static file = 21ms + 0.19ms per Kbyte
    FastCGI = 22ms + 0.28ms per Kbyte

    That puts static files at 5.3MB/s and FastCGI static files at 3.6MB/s. I did my own test of a 113MB file on my own computer and the static file got 121MB/s while the Mono static file got 46MB/s. I expect this is because the Mono file has to travel twice as far and the difference would be much less when traveling over the internet. I recommend doing some additional testing of your own.

    I would suggest either (A) using mod_rewrite to check for the file’s existence and redirecting it (if possible), or (B) copying the source from StaticFileHandler and modifying it to check for the remote file if the local file doesn’t exist. This would probably be faster than catching the file not found exception.

    The concept sounds interesting, good luck!

    Sincerely,
    Brian Nickel

Leave a reply to Michael Bradley Cancel reply