On 9/26/05, Phil Ehrens wrote:
> Pigeon wrote:
> > (The reason I say 10k concurrent is because we have an update system (s=

orta
> > like windows update).. and as soon as we tell their computer to update,=

we
> > have 10k boxes saying give me the file!)


I think I agree with the guy who said this thread has pretty much been
asked and answered at this point, but I figured I'd just throw in one
more little nugget for you to think about.

It sounds to me from the limited information above that you're causing
your own problem here by instructing 10k-100k clients to update
themselves with some multi-megabyte patch file simultaneously. This
is obviously a huge amount of bandwidth, but it doesn't seem obvious
to me that it would be a huge amount of bandwidth on a 24/7 basis...
rather it would come in bursts _at times specified by you_. This to
me begs for a software engineering effort rather than a
sysadmin/netadmin effort; if you can get the clients to wait some
random length of time after receiving the "update available"
notification prior to requesting the update, your number of concurrent
accesses will drop dramatically. Alternatively, if you have more
control over the server-side code than the client-side code, you could
publish the "update available" notification TO the clients a handful
at a time rather than all at the same time.

Hope this helps, and best of luck...

--Cliff
__________________________________________________ ____________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org