httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Sutherland <ja...@cam.ac.uk>
Subject Re: [module porting] mod_proxy
Date Wed, 22 Mar 2000 20:48:06 GMT
On Tue, 21 Mar 2000 17:54:49 -0800 (PST), you wrote:
>On Tue, 14 Mar 2000, James Sutherland wrote:
>
>> I like the idea. Rather than having the async engine part of the main
>> process, though, I'd like it to be external. This way, you could (for
>> example) replace it with an SSL one. For high traffic sites (Netscape now
>> offer their 128-bit browser for download via HTTPS - were Cray holding a
>> spring sale or something?!) the SSL encryption/decryption is pretty heavy
>> work. 
>
>hunh.  it's not my experience that ssl encrypt/decrypt is that heavy --
>when considered against the sheer CPU cost of supporting thousands of
>modem clients as you would at any single "choke point" like the
>architecture i proposed.  although maybe my viewpoint is skewed because
>our systems at CP deal with pop, smtp, and imap traffic in addition to
>http traffic... and pop in particular has far more tiny packets than http
>in general (LIST, response, RETR 1, response, DELE 1, response, ...)

A major part of the workload in POP etc. will be handling the huge
numbers of tiny packets.

My main aim was to offload the long-duration sessions from the big
heavy Apache processes onto a single lightweight accelerator. Every
second the modem is dribbling data at 3K/sec, it's tying up one of
your processes; much better to have Apache blasting the data across
the wire very quickly, and buffered by a front-end.

>i admit to only having modelled numbers at the moment, but it appears that
>simply doubling my CPU speed i'll handle the same load as i have now fully
>encrypted.  and given that our currently deployed proxies were spec'd a
>couple years ago we've already had Moore's law bring us to within the
>realm of "should work on paper".

My main aim is not so much that one machine can't handle the load -
but if I have a 20 machine farm, I'd rather have 10 machines doing
crypto and 10 doing the HTTP and dynamic stuff than 20 machines doing
a bit of everything. Not much cost in terms of latency etc, and it
simplifies running things. Half the number of Apache boxes, etc.

>i'll report back in a few months when i've got production data.

Should be very interesting. As I say, it's not so much the CPU load
per se - I'd just prefer to have fewer Apache processes running at
once, shifting data more rapidly.


James.

Mime
View raw message