Subject: [Sip-security] how many TCP connections can be handled?

From: "Beck01, Wolfgang" <[email-masked]>
Date: Mon, 26 Nov 2001 17:37:43 +0100

TCP itself does not have a big overhead compared to UDP if messages must
be sent reliably. But with UDP, the application programmer can use a
single socket and demultiplex the incoming messages by their source ip
address and source port. There is no need to determine message boundaries.

With TCP, the programmer has to deal with hundreds or thousands of sockets
when developing a server.  The common select() and poll() system calls
are not very good at this. Multithreading does not scale too well either.
Multiple reads may be necessary to receive a complete message.

Faster constructs like /dev/poll (Solaris, Linux), kqueue()/ kevent()
(BSD) or Mach's port sets are not commonly used at this time.

Some numbers:

The SPECWeb99 pages (http://www.spec.org/osg/web99) contain http server
benchmarks. SIP proxies have not as much disk IO, so the 'Conforming
Simultaneous Connections' displayed there will be higher for SIP. With
in-kernel http server support (TUX 2.0) the number of Conforming
Simultaneous Connections doubles.

One source says that SSL reduces the [http] server capacity
by 33 - 50 percent depending on the strength of encryption used
in the connection. A different source talks about a reduction
of 17 - 22 percent.

Time to make some tests with openssl..

--
Wolfgang Beck
T-Systems Nova GmbH 

_______________________________________________
Sip-security mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/sip-security

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Nov 2001 13:05:34 -0500

> -----Original Message-----
> From: Beck01, Wolfgang [mailto:[email-masked]]
> Sent: Monday, November 26, 2001 11:38 AM
> To: [email-masked]
> Subject: [Sip-security] how many TCP connections can be handled?
> 

So what are the commercial web servers using? With http 1.1 they will need
to handle lots of concurrent connections.

> in the connection. A different source talks about a reduction

THis probably depends a lot on your assumption about churn in the
connections. With SIP, the SSL connections could be long-lived, avoiding the
PKI overheads. 

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Beck01, Wolfgang" <[email-masked]>
Date: Tue, 27 Nov 2001 16:08:56 +0100

[email-masked] wrote:
> 
> So what are the commercial web servers using? With http 1.1 
> they will need to handle lots of concurrent connections.
They do, but according to the SPECWeb99 pages it takes a lot
of horse power to handle more than 1000 concurrent connections.
Apache for example, forks a process for every connection. This is
a portable, but not very scalable solution. The fastest web
server was implemented as part of the kernel.

Handling a large number of active TCP connections
is a problem. If you have one thread per connection, programming
is easy but you have the thread overhead in addition to the
(negligible) TCB. If you have more than one connection per thread,
programming becomes more difficult and your OS must provide better
system calls than select() or poll().

I've done a small test program under FreeBSD: it accepts
connections and creates threads for them (FreeBSD uthread).
The thread starts the TLS (openssl) and exchanges 3 small (120 byte)
messages. It closes the socket and waits some minutes before it
exits. 'ps' before and after having connected 3000 sessions
shows that each connection needs about 5 Kbyte. The load on the
PIII 850Mhz is low as the TLS initial exchanges and the encrypted
test messages are sent one after the other in my test.

> connections. With SIP, the SSL connections could be 
Agreed. And with SIP, the connections will be much less busy than with
http. The numbers I've quoted include the performance penalty
introduced by any encrypting method, though.

--
Wolfgang Beck
T-Systems Nova GmbH