High-performance Windows Sockets Applications ;-)

Marc Lehmann schmorp at schmorp.de
Wed Jun 4 10:07:12 CEST 2008


On Wed, Jun 04, 2008 at 08:52:13AM +0200, Aleksandar Lazic <al-libev at none.at> wrote:
> there is a High-performance Windows Sockets Applications description,
> anybody used it?
> 
> http://msdn.microsoft.com/en-us/library/ms738551%28VS.85%29.aspx

Thanks, that looks interesting, but after reading through it, here are the
vastly suprising tips we get from microsoft to achieve high performance :)

- don't connect more often than neecssary
- disable nagle (great suggestion in general...)
- transfer less data if possible
- compress your data if possible

and as for future improvements:

- use only one conenction and keep it open
- combine multiple replies into one send
- use threads to overlap (blocking) network I/O
  with computations

Now, except for the very last suggestion, that's hardly any news to anybody.

And if the last suggestion is meant seriously, then, well, forget about
libev, on windows, you do not use non-blocking I/O at all, you don't use
events, you use THREADS.

and that might well be true... to get perfromance out of windows, use
threads. preferably thread pools.

and thats the best windows can do (windows threads are quite slow and
high-overhead, but completion ports effetcively force their use).

now, for windows specifically, the problems are elsewhere - for sockets, you
can actually get "async. notifications" (they are synchronous of course), but
you need a window handle.

from what i have gathered so far, requiring a window handle in a pure
server application is a bad idea, and forcing one into the libev API seems to
be a bad idea as well - I personally prefer an API-compatible library
that "just" works on windows as well over  ahigh-performance library that
uses a different API - I can then use the platform-native approach.

that kind of leaves threads - microsoft also recomemnds to spawn a thread
for every 63 (sometimes 64) handles you have and then wait for them (64 is
the maximum number of objects a thread cna wait for at any one time).

this might be much more efficient than the current select backend, and
afaik doesn't need a window handle. and it might even work for non-select
handles (for example, you cna wait for the console in that way, but there
is little else you can wait on).

another option would be overlapping I/O - apparently some windows versions
support waiting for readyness notifications that way, but then only on some
handles.

my suspicion is that when you force any windows mechanism into the posix
model, you will get lots of headaches, and most of the performance gain
will be eaten up by the workarounds required.

but then, if somebody wrote code and it worked and was performant I would
be the last one to complain. The issue is simply that the libev/posix
model doesn't map on windows, and will never ahcieve bets possible
performance.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg at goof.com
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list