[Zope] TUX and Zope? + ab results

[sean.upton@uniontrib.com]

Caching w/ TUX, AFAIK, isn't going to be as efficient as Squid.  I think
that likely the reason is that TUX is a webserver and not a cache, and that
(if TUX can cache; I think it can just proxy!) the overhead to proxying
likely mitigates a lot of the magic marshmallows in TUX like Zero Copy,
checksum caching, etc - a network copy is going to add latency, and cache
machinery is going to eat some CPU cycles.  Somebody correct me if I am
mistaken here.

Tux might work well with ExtImage/ExtFile and TUX's machinery for serving
some URLs and passing on others to another server (Apache, ZServer...).  For
predictable content, that is served over and over, seems like Squid in http
accelerator mode is a better solution...

Sean


-----Original Message-----
From: John Morton [mailto:jwm@plain.co.nz]
Sent: Wednesday, May 02, 2001 10:36 PM
To: Jason Byron; zope@zope.org
Subject: Re: [Zope] TUX and Zope? + ab results


On Thursday 03 May 2001 13:01, Jason Byron wrote:
>  This may sound silly, but do you think it would be
>  feasably to get some more speed out of Zope by
>  combining it with TUX (the linux kernel based web
>  server) ?  Maybe build the python interpreter into
>  it ?

TUX is a linux only thing ATM, so any integration of the two
would have to be some sort of add on to a vanila zope.

> TUX       2898.55 Requests per second
> AOLserver  603.14 Requests per second
> Apache     502.51 Requests per second
> Zope        60.57 Requests per second

There are important reasons why the figures are so different. In
the case of TUX, the kernel server tries to do as little work as possible
to translate a request into data flying out the NIC. Zope, on the other
hand,
at the very least checks to see if the requester has permisson to access
that
object, and often looks after other things like acquisition, setting caching

headers and obviously executing content generating code.

The easiest way for Zope to take advantage of TUX would be to have a TUX
based
caching reverse proxy sit in front of the Zope server. All of the images and

other static content window dressing for the site which will always be
served 
up to everybody can have cache TTLs set so they quickly end up in the proxy,

which can serve them up as fast as they can go.

If you still want to crank more speed out of zope, the next thing to do
would 
be to profile the steps needed to serve up requests for static content where

having a permission system matters, and look into optimizing that.

John


_______________________________________________
Zope maillist  -  Zope@zope.org
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )