You're not looking at your problem from the right angle.

10K users... asking for the SAME file. Set up a smallish farm of four or
five machines and use a HTTP Acclerator. (basically a Squid proxy turned
on it's head - the examples exist in the config file for squid .. look at
the http accelerator mode).

Then use an SSL terminating proxy cluster on the frontend .. now you have
0 disk contention since the file will be sent straight from RAM.

What you now need to know is the distribution of connection speeds for
your users. If they're on T3's, you have no choice but to go with GigE.
... Frankly, you're probably looking at some sort of GigE burstable produc=
offering anyway.

Ok .. enough's enough .. Your original question has been answered long ag=
and you've heard from everyone with additional information and ideas.
We're getting very close to the point of engineering this solution for
you. Either you can take it from here or hire some of us as consultants
to work out the rest of the engineering for you. Free software is one
thing .. free engineering is quite another.


> Ok, lets assume I can get a network connection with:
> A)10mbit
> B)100mbit
> C)1000mbit
> And I will have 10k concurrent downloads (let us throw out 100k for now=

> because i can alwasy scale up figures if we get a base).
> (The reason I say 10k concurrent is because we have an update system
> (sorta
> like windows update).. and as soon as we tell their computer to update,=

> have 10k boxes saying give me the file!)
> So my question is..
> What would be the best (given we cannot do blades or the like since we
> have
> to use 'standard' 1u/2u/4u boxes from the dedi center).
> Should we definitly beat the problem with iron and get 5servers doing l=

> balancing? 2servers? If 2servers go with the 1000mbit connection?
> thank you for all of your time and input!
> thanks
> Lee
> ----- Original Message -----
> From: "Mads Toftum"
> To:
> Sent: Monday, September 26, 2005 1:27 PM
> Subject: Re: Mod_ssl and how to reduce overhead
>> On Mon, Sep 26, 2005 at 11:28:11AM -0400, Pigeon wrote:
>>> Hmm.. 10k -100k are pretty much guaranteed numbers..

>> That's quite a wide margin. Are we talking concurrent users or just
>> number of people who could be using it over a period of xx?
>>> So my main computer crunching will be done at the beginning? (and to
>>> relive
>>> this I can do session key caching.. how long can I cache a key? is th=

>>> 'secure'?) (also.. all transfers will be ~15megs in size)

>> well, with 15meg files you've got more work to do encrypting the conte=

>> as the session goes along. You can cache the key as long as you want,
>> but depending on the type of encryption used, most browsers will not
>> allow the key to live for all that long. I usually run for about 1 hou=

>> but ymmv depending on the chosen parameters.
>>> And using a single server is out of the question?

>> the number of concurrent users has very much to say in that regard.
>> Maybe an ibm power 5 64 proc or a fully loaded sun e25k - and add an
>> ssl accelerator to the mix.
>>> If we just go with one server.. shouldn't it be something super fast.=

>>> amd64 1gig ram?

>> Super fast / amd 64 with only 1 gig mem? you've got to be kidding - I'=

>> pretty sure you couldn't keep even without SSL.
>> Doesn't your pr0n streaming business generate enough income to pay for=

>> real server?
>> vh
>> Mads Toftum
>> --
>> `Darn it, who spiked my coffee with water?!' - lwall
>> __________________________________________________ ____________________
>> Apache Interface to OpenSSL (mod_ssl)
>> User Support Mailing List
>> Automated List Manager

> __________________________________________________ ____________________
> Apache Interface to OpenSSL (mod_ssl)
> User Support Mailing List
> Automated List Manager

__________________________________________________ ____________________
Apache Interface to OpenSSL (mod_ssl)
User Support Mailing List
Automated List Manager