[lug] off topic web Q

[D. Stimits]

rm at mamma.varadinet.de wrote:
> 
> On Thu, Feb 01, 2001 at 07:48:17PM -0700, D. Stimits wrote:
> [...]
> > They use entire
> > Sun machines, not a shred of windows anywhere. The site that is in need
> > of some big changes (it's basically the same "stub" site it was
> > originally set up for, strictly to get some source code to some
> > developers...the software is being completely redesigned from legacy
> > code) is:
> > http://www.battlefieldlinux.com
> >
> > Almost everything about it is like Apache, except that it is designed
> > for hosting services (it is the Zeus web server).
> 
> Ah, ok.  Just out of curiosity: where would you say Zeus is better/easier
> than Apache for server hosting? The box i mail this from houses about
> 60-100 domains (I gave up counting long ago). While i would label most
> of these 'dormant' (Carpenter X goes eBussiness :-) some actually have
> quite a lot of hits (http://www.schauinsland.com/ for example) and
> there's quite a bit "fancy" stuff going on (like Zope servers behind
> Apache, postgreSQL based message system etc.).
> So far i never found Apache not capable of doing what i wanted (i some-
> times look after the server in exchange for mail services).

FYI, Zeus runs on linux too, this just happens to be on SunOS. For the
most part, take this description with a proverbial grain of salt, since
I'm just one user. The version that is relevant is the mass hosting
edition. Check:
http://www.zeus.com/products/mhe1/

For the most part this is very close to Apache (I don't consider it
"better" in final results), but I haven't had to do much in terms of
admin, only for the one virtual site (not as an ISP). Both seem quite
similar. In general, I think one of the keys to Zeus' appeal is in the
tool set available to instantly configure both security and virtual user
setups such that each domain user gets a virtual-root-privilege within a
sandbox (I'm not really root on that machine, but
root at battlefieldlinux.com goes to me...this sandbox gives the appearance
of adding privileges, rather than restricting...yet it insulates); the
users have more control than a regular non-privileged user does for
Apache setup, yet there is a great safety that different users won't
interfere with each other (the sandbox). Adding and removing accounts I
believe is easier, since it adds or removes more than web sites and
users, but also related sandbox security. If you were to be in the
business of adding and removing dozens of domains (not just web sites,
but DNS and all) per day you would probably find it convenient (their
domain registration rates are very competitive). It is reliable as well,
I've never ever seen it crash or misbehave, or even respond slowly. If
you understand Apache configuration, you can almost configure a
particular Zeus account by guessing, they are nearly identical end users
of the created sites (versus the tools that the ISP's use to create the
virtual accounts, which are more advanced).

> 
> [...]
> > Probably I will give in and use javascript, but I absolutely hate the
> > idea. Testing it to work correctly, even for simple things, is a pain
> > with the different flavors of browsers (of which all are broken in some
> > way, or just different).
> 
> Yes, i hate JavaScript too.
> It's just insane. And given the bad security records it has since some-
> one invented it (or better: patched it together) i try to stay away
> from it.

People sometimes think I'm nuts when I prefer to use C++ over javascript
where possible. But C++ leaves me with more of my dwindling sanity at
the end of the day.

> 
> > What I was thinking of was the possibility of more intelligent caching,
> > where I could instruct the cache to check for pieces of the page for
> > change or not, and send only the pieces. I'd read somewhere about the
> > possibility of more intelligent caching, but never could remember where
> > (or if it was just a wish list).
> 
> Well, if your server sends the 'right' headers most of the static content
> will come from the local cache anyway (images and other multimedia resources).
> Anyway, even if you would resend all of the html code, how much data would
> that be? Compared to even moderatly sized images i think you can neglect
> html code size. In my experience there are basically two bottlenecks that
> affect the perception of speed of a website:
> 
>  The number of tables on a page. Most browsers will only start rendering
>  a part of the page once the outermost table is closed. If all of your code
>  sits within one big table than the client has to wait for all the html
>  before she start seeing anything (tables are way to often abused as layout
>  managers these days).
> 
>  On a much smaller scale: Opening/closing of tcp/ip connections. Many small
>  images are really bad. This will be/is taken care of by HTTP/1.1 which
>  allows for connections to stay open at the transport layer as well as for
>  chunking of content.

This is something I might investigate but it leaves me with a question.
Since cgi gets its information via environment variables on each hit
(one of those reasons Apache forks instead of threading...makes it easy
to get new environment variables each hit), is it able to still
open/close the cgi each hit, while maintaining the connection? Is there
an environment variable that also gets passed during this static
connection, as a kind of session key? If so, it would make it easier to
keep a given session state without messy cookies and javascript argument
passing.

> 
> One (not too pretty solution) is using frames. If you don't overdo it
> this is probably the way to go. I like the sidebar on Zopes managment
> interface for example. Intuitive to use and pretty fast.

I actually like frames, and aside from people running 640x480 or less (I
tend to use 1600x1280), haven't much understood the resentment of
frames. Maybe that is because I haven't had to deal with badly written
frame sites (how might bad frames cause frustration for the average
user?). FYI, if anyone knows of a badly written frames site, as an
example, I'd like to see it (as a case of what to avoid).

> 
>  Ralf

D. Stimits, stimits at idcomm.com