Windows posix sockets performance

I am looking for information on Windows network programm开发者_C百科ing. Mainly how to get a single executable to cope with 1000 connections.

We use select() FD_ISSET etc on unix and this works very quick. On Windows these APIs are very poor. FD_SET is lots slower but even when working around this, Windows is lots slower than HPUX.

I'm looking for a win32 API call which I can use instead of the select() call which doesnt require so much CPU/time. Currently we spend 50% of the time (and CPU) in select(), where as on unix the time spent in send() and recv(), which is what I would expect.

Thanks Neil

---

You are probably looking for Windows I/O Completion Ports. Here's an article from SysInternals guys.

---

If you are really into the scalable sockets programming, nothing would outperform IO completion ports on Windows.

Having said this, you program would likely need a big rewrite for completion ports model.

However, it is possible to improve performance even with select()/FD_ISSET.

Here is how it can be done: in winsock2.h fd_set is defined as an array of SOCKETs and a element counter

typedef struct fd_set {
    u_int fd_count;               /* how many are SET? */
    SOCKET  fd_array[FD_SETSIZE];   /* an array of SOCKETs */
} fd_set;

Also in winsock2.h you'll find that FD_SET adds a SOCKET at the end of this array, and FD_ISSET is doing a linear search in the array.

Now if you change macros to use sorted array of SOCKETs, i.e

• FD_SET adds sockets in the sorted order
• FD_ISSET does binary search instead of linear

then dependent on the size of the array FD_ISSET can be greatly improved (while performance of FD_SET will degrade somewhat, but we're assuming that FD_SET is a seldom operation).

On Unixes, performance of select() is better since they FD_SET as bitmap, FD_SET/FD_ISSET would just test or set a bit. On Windows this technique would not be applicable because socket is not a small positive file descriptor number, it is a HANDLE and scalar value of a handle can be large.