Hi Kelly, just catching up on this thread; see below for my view on what the alternatives to get good performance and scalability on Win32 are.
[email protected] said: > > Yes. This is a problem with all Microsoft products. Porting 0MQ to to > > Win32 took approximately 50x more time than porting to any other > > platform. IOCP seems to be no different in this aspect. > > Well, while I'm not a MS fanboy, I will give them the benefit that > IOCP "can" be more efficient and have lower latency than epoll or kevent > versions. On the other hand, is 5% reduced memory bandwidth and slightly > more linear scaling really worth all the extra work? I don't think so > personally, I'd rather just buy another server instead of wasting weeks of > time.. $2k-$3k for another server is cheaper in the bang for the buck > department compared to time optimizing for a minor gain. When I looked at the state of the various Winsock I/O models available, I found Network Programming for Microsoft Windows by Anthony Jones and Jim Ohlund to be by far the best (and probably only comprehensive) literature on the topic. Especially interesting is the performance comparison of the various models in table 6-3 on page 124. The book is available on Safari or copies of an older edition are floating around on the net if you look hard enough. IOCP obviously offers the best performance and scalability (in terms of number of connections that can be handled by a single thread) but the downside is the large amount of work required to make it work since the I/O model is so different. An interesting intermediate step from a performance point of view might be to use WSAEventSelect() instead. This gives very good performance, however it suffers from the limitation that a single thread can only wait for a maximum of 64 event objects using WSAWaitForMultipleEvents(). I've not thought about this in detail, but it could possibly be worked around by creating worker threads inside the zmq::poller_t object; ugly but usable and still possibly less work than a full-blown IPC implementation. Note that it's not clear whether or not WSAWaitForMultipleEvents() can be used on anything else besides sockets; i.e. if you can create an event object for a Named Pipe. This would also need to be investigated for the IOCP model; if we could get Named Pipes to work it would eliminate the horrible socketpair emulation used internally by zmq::signaler_t which causes all sorts of problems on Win32 (see e.g. issue#84 on Github). Another alternative for implementing both the ipc:// transport on Win32 and a better zmq::signaler_t might be to use LPC: http://www.zezula.net/en/prog/lpc.html To summarize; there are several options out there, all better than what we have now. Advice, experience from the Win32 trenches and above all actual code is appreciated :-) On another note, in a separate message in the static linking thread we talked about which versions of the Win32 platform to support. In my opinion we don't need to care about anything pre-XP for any of this stuff, or if someone really cares we can of course fall back to the existing select() implementation which will limp along ok ... Cheers, -mato _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
