High-performance Windows Sockets Applications ;-)
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?
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
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
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
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