|
Home > Archive > Web Servers on Unix and Linux > February 2006 > capacity planning with ssl
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
capacity planning with ssl
|
|
| synfin80@gmail.com 2006-02-13, 6:01 pm |
| Does anyone have any good resources or experience with capacity
planning? I'm working on building a web server that will primarily be
handling ssl connection. All of my searches have come up empty handed.
What is a good way to estimate the number simultaneous SSL connections
that a server will be able to handle (not worrying about network
bandwidth)? I know SSL can severely limit the number of concurrent
connection because of the processor load for handshake/encryption, but
I can't figure out a way to get realistic estimates.
| |
| Paul Rubin 2006-02-13, 6:01 pm |
| synfin80@gmail.com writes:
> What is a good way to estimate the number simultaneous SSL connections
> that a server will be able to handle (not worrying about network
> bandwidth)? I know SSL can severely limit the number of concurrent
> connection because of the processor load for handshake/encryption, but
> I can't figure out a way to get realistic estimates.
Type "openssl speed rsa" on your server and see how many decryptions
per second it can do at the key size you plan to use (normally 1024
bits). For a typical x86 server today (let's say 2 ghz P4 or Athlon),
that might be around 300 decryptions/sec. So with 10% cpu load going
to decryption, you can accept about 30 SSL connections/sec. Normally
the SSL session key is cached across browser connections (plus,
browsers usually will use http 1.1 keepalive) so you won't have to
decrypt again whenever the person clicks around. Basically the SSL
handshake just isn't that big an issue any more unless your site is
enormous. If you really want to take a lot of connections, there are
some special 64 bit RSA implementations for the athlon-64 that are
extremely fast, but just using stock OpenSSL is plenty fast enough for
most purposes.
Of possibly more significance, browsers usually don't cache resources
as aggressively when SSL is enabled. That only makes sense: you don't
want confidential stuff sitting around on the hard drive. But it
means you should try to keep your SSL pages lightweight, not too many
images and stuff. If you look at the SSL checkout page on a typical
retail site, you'll see they're usually less cluttered than the
shopping pages, for this reason.
| |
| synfin80@gmail.com 2006-02-14, 5:51 pm |
| Cool, thanks for your help Paul
|
|
|
|
|