[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: What is TUX? (Was Re: A heads up)



A few things:

First, this is a little moot, as the TUX maintainer is busy working on the
2.5 kernel, and it's far too complex for most non-heavy kernel devs to
even think about adding features to. I really, really need a high-speed
webserver for my own future projects though. So far, fnord looks like the
best, and it's missing quite a lot I need.

Second, if you have a server with enough traffic to require TUX,
keepalives are memory suicide. It would be nice if TUX could hold
keepalives and proxy requests back through to apache, however. That would
likely increase client throughput slightly, but it doesn't matter in the
long-run. Not having keepalives enabled on your high memory-usage dynamic
generators is a first step speedup. For the case as is, TUX will probably
help you more with all keepalives off than you would gain by having not
quite as many build-ups and tear-downs. TUX's big shine is in its ability
to handle hundreds/thousands of concurrent connections, keepalives or not.

TUX is a webserver, but it's an incomplete one. A good portion of its code
relies on a backend server, so that it cannot be used for most websites
without an apache to lean on. Sure, you can set it up to dish out static
content and nothing else, but I bet there're Squid hacks to do the same.

have fun,
-Dormando

On Sun, 16 Mar 2003, Miles Elam wrote:

> Indeed, I looked back through the archives and found some mention of the
> issue...it was before I subscribed to the list last September.  Since
> the search on the Redhat site appears to be broken for me, and I hadn't
> been a part of the previous discussions, I merely assumed.
>
> As for nomenclature, TUX *is* a web server.  It is simply a
> static-content-only web server (I'll leave the userland modules out for
> the sake of this discussion).  If I type in the following:
>
>   GET / HTTP/1.1
>   Host: www.foo.com
>
> it will return a perfectly valid web server response if there is a
> index.html file present in docroot.  If your web site is completely
> static, it can function without any outside assistance whatsoever.  If
> the resource isn't found and there is no backend server, TUX sends a 404
> all by itself.  This is in contrast to Squid where, in accelerator mode,
> if there is no backend web server, it cannot provide content.  Squid can
> be a true accelerator.  TUX, at worst, is a hybrid.  By this metric, TUX
> should be *expected* to serve all static content.  If it does not, it's
> raison d'etre is lost: there is no point to it.  The early versions of
> CERN did less than TUX (content ranges, content encoding, etc).  Does
> this mean that CERN was not a web server?
>
> The deviation that you speak of includes "..", "?", and special file
> cases like PHP and JSP.  ".." is a potential security issue.  Dynamic
> content (commonly marked with "?") gets forwarded to another service.
> This is not fundamentally different from Apache opening a socket to an
> external Tomcat JVM process to serve a JSP file -- even if Tomcat is not
> configured to serve static files in the directory.
>
> While its primary purpose may be to accelerate a userland web server, if
> its proxying/referral capabilities exclude it from the definition of
> "web server," Apache must be excluded as well since it can proxy/relay
> to another web server as well.  ;-)
>
> TUX is indeed a web server: a web server optimized to accelerate access
> to static resources and redirect all other requests to an optional (but
> recommended) secondary web server.  I don't believe that I have
> misunderstood TUX...err...the Redhat Content Accelerator.  I am simply
> intent upon making it do something useful so that the load drops for
> userland -- the whole point to TUX in the first place.
>
> Given) My textual content is dynamically generated with images, CSS,
> XSLT, Javascript, etc. as static resources.
>
> Premise 1) The text content (HTML) will always be requested as the first
> browser request and is forwarded to the backend server which thereafter
> has total control of the socket.  (How would a browser know about an
> image if not for the <img> element?)
> Premise 2) TUX misses >90% of the requests on my box if keepalives are
> enabled and the backend server can serve static files as well.
> Premise 3) If TUX misses >90% of the requests because userland uses
> keepalives, TUX loses any real, measurable benefit -- TUX's advantage is
> lost in the content delivery noise.
> Premise 4) If TUX serves all of the static content because the backend
> has keepalives disabled (or something similar), then it is as much a
> part of the content generation model as your backend server.
> Premise 5) If it's a intregal part of the overall content generation
> model, configuring the backend to serve static resources is redundant
> and useless.
> Conclusion 1) You must configure TUX to serve 100% of all static content
> (through disabling keepalives) or omit it from the chain as unnecessary
> processing overhead since almost everything bypasses it anyway.
> Conclusion 2) TUX is *the* static web server or TUX is useless
> (especially if you have mostly dynamic content without regard to the
> number of static elements used in conjunction with the web page).
>
> If the given changes to include static content, TUX becomes *even more
> important* to the content delivery model.  The only given where TUX
> becomes less important is with static content and dynamic images -- a
> very small niche.
>
> See my point now?  You cannot just assert that it's just "a web
> accelerator" without completely disregarding it as an unnecessary
> variable in your web setup.
>
> - Miles





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []