Re: [WIN32] Using WSAPool for Vista+

[Bing Swen <bs...@pku.edu.cn>]

"Mladen Turk" <mt...@apache.org> 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

Re: [WIN32] Using WSAPool for Vista+

[Mladen Turk <mt...@apache.org>]

Paul Querna wrote:
> Mladen Turk wrote:
>>
>> Since it seems there is no point of having generic
>> apr_pollset provider API, current select implementation
> 
> we should consider making it dysnamic on all platforms, and selectable
> at runtime, we have this problem on more platforms than win32.
> 
> 

Even better, since no need to duplicate the code then.
Extending flags in apr_pollset_create to include
the desired provider (none presumes current default)
and probably apr_poll_ex with provider flags
should be enough for start.


Regards
-- 
^(TM)

Re: [WIN32] Using WSAPool for Vista+

[Paul Querna <ch...@force-elite.com>]

Mladen Turk wrote:
> Bing Swen wrote:
>>
>> But there seems no reason not to use WSAPoll to implement
>> apr_pollset_t (when _WIN32_WINNT >= 0x0600), at least for such
>> performance gain.
> 
> It's not that simple.
> Since apr binary needs to work on any NT (trunk on 2K+) version,
> we cannot use a simple pollset replacement.
> It has to dynamically check for the WSAPoll presence in
> ws2_32.dll and then choose the pollset provider.
> 
> Since it seems there is no point of having generic
> apr_pollset provider API, current select implementation
> we are using from poll/unix/select.c and  poll/unix/poll.c
> would need to go to new poll/win32/poll.c as implementation
> function pointers. Actual API would call either WSAPoll
> (if present in ws2_32.dll) or standard select.

we should consider making it dysnamic on all platforms, and selectable
at runtime, we have this problem on more platforms than win32.

Re: [WIN32] Using WSAPool for Vista+

[Mladen Turk <mt...@apache.org>]

Bing Swen wrote:
> 
> But there seems no reason not to use WSAPoll to implement apr_pollset_t 
> (when _WIN32_WINNT >= 0x0600), at least for such performance gain.

It's not that simple.
Since apr binary needs to work on any NT (trunk on 2K+) version,
we cannot use a simple pollset replacement.
It has to dynamically check for the WSAPoll presence in
ws2_32.dll and then choose the pollset provider.

Since it seems there is no point of having generic
apr_pollset provider API, current select implementation
we are using from poll/unix/select.c and  poll/unix/poll.c
would need to go to new poll/win32/poll.c as implementation
function pointers. Actual API would call either WSAPoll
(if present in ws2_32.dll) or standard select.


Regards
-- 
^(TM)