I would like to throw in something I've been thinking about for the last week or so. I would like to use Tux as the front-end of my website. For info on Tux. ftp://ftp.redhat.com/pub/redhat/tux/tux-2.0/ http://www.redhat.com/products/software/ecommerce/tux/
From the website: """TUX is a kernel-based, threaded, extremely high performance HTTP server. It is able to efficiently and safely serve both static and dynamic data. TUX moves the HTTP protocol stack to the kernel, and can handle requests for data with both kernel-space and user-space modules."""
It has been reported to do over 10,000 requests per second on a static html file of 1666 bytes. It did over 1,000 rps doing a cgi program, opening and closing the cgi app each request. I read this from Linux Weekly News which got it off of the Linux Kernel Mailing List.
From what I understand Tux 1.0 holds the SpecWeb record. Tux 2.0 is faster. :)
I think it would be interesting to see Zope fronted by Tux. If there were a Tux cache manager for Zope that would be awesome. I've been trying to figure out how to maximize what Tux can serve and what Zope can manage. An optimal mix between the two could create a very manageable and fast website. Tux primarily caches what is available on the file system. It can serve multiple files (objects) sequentially as instructed by the "user module" as part of a single client request, thus assembling the request to send to the client. I'm butchering the explanation, but any ways, it's fast. Unfortunately, I am still working on understanding Tux and how to best use it. I don't program C and so reading the sample code hasn't sunk in yet. I don't know how to integrate it with Zope. It would be great it one of the brilliant people on this list could figure this out. :) :) :) Just thinking out loud. Jimmie Houchin Andy McKay wrote:
Ok whack idea #34... Well sort of, the idea was sparked by ExtFile (yes its all his fault honest). We want to have files on the file system for many reasons which I won't go into now, just take it for granted. But we also want some of the objects information to be in the standard data.fs, so we can catalog it use acquisition provide a simple interface to it and so on. So far you are saying thats ExtFile and you are right.
But we want to extend it to any object anywhere, instead of storing the data attribute in the object and pickling it in the ZODB I want to be able to store the data attribute on the file system. This gives us loads of advantages we also thought this would be extremely useful to other people. We've bounced around ideas on how to do this and here the only two so far:
- we could overload the data attribute with a class that on Pickling into the ZODB instead writes it on to the filesystem... - we could in the ZODB put a hack to say if pickling something with so and so attribute do this instead...
I feel like this something I should just not be doing, but it would be great if I could get it work...
-- Andy McKay.