[Zope-dev] Storing part of an object on the file system

[Jimmie Houchin]

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.