"Mladen Turk" <[email protected]> wrote on 2009-2-9 17:25
Hi,
Vista (Server 2008) and up comes with new winsock WSAPoll API.
Now I did some experiments and it compiles the unix/pool.c
by simply changing poll( ... ) to WSAPoll(...)
There is also no limitation on pollset size (currently
select is limited to FD_SETSIZE 1024, cause it's too slow
for higher numbers). Well, the testpoll.c passes
with 16K sockets.
Httpd works like a charm with 10K connections.
Now the problem is that to be able to use it,
we would need a pollset implementation
provider that will dynamically switch back to select in case
winsock doesn't defines WSAPoll.
That makes me think we can have that generic, allowing
different pollset providers for non-windows platforms
as well (If it makes sense of course), eg. something
like we have for proc_mutex.
(apr_proc_mutex_unix_lock_methods_t would actually become
apr_poll_methods_t allowing choosing different
poll providers, again where it makes sense)
As I've learned , WSAPoll was designed to behave just like the Unix poll(),
but it seems to have got counterpart performance of Linux epoll. Some
Windows port of Nginx has used WSAPoll to simulate its ngx_poll_module.c on
Windows 6.x (Vista and 2008), and seems to achieve the same performance
improvement. Though like poll(), this is just a single-threading I/O model,
and thus it should be less efficient than the IOCP (completion port) API.
It's not uncommon for a single online game or IM server that uses IOCP to
handle 100K+ (slow & long-duration) connections with quite a few (4~8)
threads.
But there seems no reason not to use WSAPoll to implement apr_pollset_t
(when _WIN32_WINNT >= 0x0600), at least for such performance gain. That
could also benefit httpd a lot, e.g., the worker MPM of httpd using
apr_pollset_t will be easily ported to Windows 6+, and possibly has the same
(or much better?) network I/O performance than the current Windows MPM
version winnt_mpm, which currently uses a suboptimal ICOP scheme.
Bing
----
School of EECS
Peking University
