httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: mod_proxy: proposal for v2.0
Date Tue, 08 Feb 2000 19:48:30 GMT
James Sutherland wrote:

> Split by vhost (one entry per file, in a different file depending on URL)
> or by content (different entries in multiple files)? In either case, I'd
> use a cron script to split up log files as needed, rather than imposing
> the extra overhead directly.

We log split per v-host. We generate a few hundred gigabytes of logs per
month, and the compression and analysis already takes a whole lot of
numbercrunching - we want to avoid more.

> Or use the backend server logs, with a suitable script to merge entries as
> needed.

The backend logs are useless, as they don't have the client IP address
logged. But regardless, we moved away from backend logging due to the
unreliability - each box type needed it's own way of distributing
logfiles for analysis, it was a nightmare - been there, done that, found
a better solution.

> > password protect arbitrary URLs
> This is done by the backend server as normal.

Yuck! We standardised on LDAP across the board. No more need to
configure Apache, IIS, Netscape Enterprise, etc etc to use LDAP,
assuming the backend server isn't totally out of our control (as some of
them are).
 
> > or support SSL (direct SSL, not SSL tunneling),
> True; depending on requirements, I would either use one [group of] servers
> in a round-robin serving secure content directly, or have SSL front end
> boxes running Apache+SSL.

And thus no URL policy - each SSL site would have to be a separate vhost
and we would be back to square one, and - we would have a different
server structure of HTTP and HTTPS. Yuck.

> Depending on what "us" requires, I would be more inclined toward the Squid
> solution; I would have thought the overhead of multiple extra Apache
> layers handling every request would more than outweigh the benefits of
> having the log files divided up realtime, rather than only every few
> minutes...

We currently use only a single layer, and the simplification in server
management that we have achieved to date has been unbelievable. Squid
would have had to have been bent and customised to achieve what we have
achieved so far, and would have turned into a management nightmare.
Apache does 99% of what we need right out of the box without any
tweaking or writing anything at all. We went through 3 weeks of
frustration trying to get Netscape Reverse Proxy to do the job for us
and ran into all the problems Apache has solved for us. I don't believe
our experience with Squid is likely to be much different.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight...

Mime
View raw message