IP Networking

Alternatively consider pthreads. If your application takes advantage of threads for concurrent activity it will scale better on SMP hardware.

You sure don't mention many details. Not even which OS you use. "Connections"... so you are awaiting connections from a listen(2)? How many fd's are involved? Lots of connections to lots of fd's is a different problem than lots of connections to a few fd's.

For lots of fd's, select/poll bogs down because massive structures to describe the fd's must be copied between user/kernel space. This is one of several problems addressed be the epoll facility which I have only seen in Linux. (But note that fd_set can be large with modern implementions. People need to stop assuming it is an int!)

Lots of connections to a few fd's can be addressed by not allowing select to get involved with every connection... instead drain the listen queue on the first select. This paper argues that when select(2) returns, accept(2) should be called in loop until it gets EWOULDBLOCK. The authors describe a considerable performance boost. You might want to try this... I thought it sounded very interesting.

Or are you reading and writing on established connections? Assuming your OS has a decent thread implementation, I would try one thread per socket in each direction that data flows.

You ask about asyncronous I/O. Traditionally this is a problem if more than one fd is involved since there is only one SIGPOLL signal to deliver to a process. Sure, you can get the signal and then do poll(2)/select(2) but this is only useful for very sparse data arriving on multiple fd's. And now with threads, perhaps it is not useful at all. Posix defines some new async i/o stuff, but your OS may not have and I have never used the new stuff.

My OS is Solaris 9. But I can also try experimenting on Solaris 10 & if there is any real performance boost, don't you think it would be possible to implement the equivalent things on Solaris 9?
I shall provide more info on no. of connections & fd's tomorrow.

Rarely does merely switching versions give you a huge performance boost.

I suggest you look at your application architecture and look for bottlenecks.

1. Do you use non-blocking sockets?

2. Do you use threads?

3. Do you parallelise concurrent activity?

4. Do you have large global locks/mutexes?

5. Does your program support SMP?

I guess, I made my statement ambiguous. I mean: I shall experiment asynchronous I/O, the new feature introduced in Solaris 10 & if that improves perfromance, implement the equivalent stuff in Solaris 9.

Now my question is: shouldn't replacing the synchronous calls with asynchronous ones improve the performance?

What is performance? Speed of handling a single client connection or total system throughput? You may find one is a trade off against the other.

Also, increasing performance may increase the complexity, robustness and maintainability of your application. It's your decision.

Threads are far easier to manage correctly than signals.

Ironically one way to improve system performance is to make applications do nothing as efficiently as possible. (as in what does an application do when it has nothing to do).