Eric Johnson wrote:
Hi. I'm new to this forum and was wondering if I could get some
assistance. I have an SSL Acceleration device that is comparable of
supporting 50,000 concurrent connections. I would like to put this in my
lab here at work and test the upper limit of this device. I'm concerned
about the backend web server needed for this test effort. I'm trying to
find out what the "appropriate" number of backend servers needed to test
the upper limit of the SSL device. If I understand correctly each
backend server is going to have an upper limit of 65535 TCP ports that
can be opened (as the Source IP will most likely always be the SSL
device). On the surface it looks like the backend server "should" be
enough to handle the upper limit of the SSL device. However, that
assumes that every connection is successful and the backend server has
enough other resources to handle the load. Does anybody have any
practical experience with this? And any recommendations on the number of
backend servers at a specific load? Thanks in advance
An SSL session is presumably mapped to a TCP connection.
A TCP connection is "named" by the four-tuple of local and remote IP,
and local and remote port number. Ignoring holes in the address space,
that means there can be 2^32 * 2^32 * 2^16 * 2^16 TCP connections in any
one Internet universe.
If you have a "well known" port number used on a server, all the clients
connect to that port number. Each of the connections will have the
server IP and server port number as part of its name, but the names will
be unique because they will also have the client IP and client port
number. Multiple connections from one client IP will have different
client port numbers, so there will still be unique names.
So in theory, a backend server can have _very_ many more than 65535
connections. However, you are correct in that to a well-known port and
a single server IP, from a single client IP, there can be no more than
65535 connections at any one time.
I suspect that if the SSL device is regenerating TCP connections, _it_
becomes the client, and so it is _its_ limitation on port numbers and
its single IP address which comes into play.
As for how many servers, that is one of those "it depends" things - how
busy are each of the connections through the SSL device etc etc. If all
you are doing is establish the connection, exchange a request and
response and then close, that will look to the back-end server or
servers rather like the old SPECweb96 benchmark. If connections are
persistent and include some dynamic content, it will look to the
back-end server rather like the SPECweb99 benchmark. If there is no
dymanic content, but connections are persistent it will look different
from the two - but a give result would be higher than the corresponding
SPECweb96 or SPECweb99 score.
If you want to be certain you are measuring the SSL device then you want
as many back-end servers as you can muster. Perhaps as many as you have
front-end clients driving the load.
rick jones
There is a crufty old "SSLperf" benchmark that took the average
request/response size from SPECweb9[69] and the SPECweb96 behaviour of
connect request response close but did it with SSL using IIRC RSA
mumble. It leveraged the "curl" utility and should still be archived on
ftp://ftp.cup.hp.com/dist/networking/benchmarks somewhere .
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
