httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bing Swen" <>
Subject Re: [WIN32] Using WSAPool for Vista+
Date Tue, 10 Feb 2009 06:38:05 GMT
"Mladen Turk" <> 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) 

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.

School of EECS
Peking University

View raw message