poor performance in windows

[gregoryyoung]

We are benchmarking at +- 5k/sec on a trivial example in windows while easily 10x this in linux. We are building with the included dlls.

Are we missing something or is it actually slow in windows?

[kekekeks]

Yes, it is. Libevent uses select instead of I/O Completion Ports. So you'd better use HttpListener which is a wrapper to http.sys kernel driver in Windows.

[gregoryyoung]

I thought as of 2.0 they moved to IOCP?

On Tue, Apr 15, 2014 at 12:25 AM, Nikita Tsukanov
notifications@github.comwrote:

Yes, it is. Libevent uses selecthttp://msdn.microsoft.com/en-us/library/windows/desktop/ms740141%28v=vs.85%29.aspxinstead of I/O
Completion Portshttp://msdn.microsoft.com/en-us/library/windows/desktop/aa365198%28v=vs.85%29.aspx.
So you'd better use HttpListener which is a wrapper to http.sys kernel
driver in Windows.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-40420281
.

Le doute n'est pas une condition agréable, mais la certitude est absurde.

[gregoryyoung]

btw can you drop me an email re: my current change set
gregoryyoung1@gmail.com

On Tue, Apr 15, 2014 at 12:27 AM, Greg Young gregoryyoung1@gmail.comwrote:

I thought as of 2.0 they moved to IOCP?

On Tue, Apr 15, 2014 at 12:25 AM, Nikita Tsukanov <
notifications@github.com> wrote:

Yes, it is. Libevent uses selecthttp://msdn.microsoft.com/en-us/library/windows/desktop/ms740141%28v=vs.85%29.aspxinstead of I/O
Completion Portshttp://msdn.microsoft.com/en-us/library/windows/desktop/aa365198%28v=vs.85%29.aspx.
So you'd better use HttpListener which is a wrapper to http.sys kernel
driver in Windows.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-40420281
.

Le doute n'est pas une condition agréable, mais la certitude est absurde.

Le doute n'est pas une condition agréable, mais la certitude est absurde.

[kekekeks]

Now I'm digging libevent code and it seems that http.c uses bufferevent API that actually has IOCP backend, so it should handle a lot of connections quite well. May be it's because of single-threaded event loop model, IOCP performs better when multiple threads are waiting for events. Have you tried EventHttpMultiworkerListener? May be it will give you better results.

[gregoryyoung]

have you benchmarked at all? are your benchmarks similar to ours?

On Tue, Apr 15, 2014 at 12:41 AM, Nikita Tsukanov
notifications@github.comwrote:

Now I'm digging libevent code and it seems that http.c uses bufferevent
API that actually has IOCP backend, so it should handle a lot of
connections quite well. May be it's because of single-threaded event loop
model, IOCP performs better when multiple threads are waiting for events.
Have you tried EventHttpMultiworkerListener? May be it will give you better
results.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-40421937
.

Le doute n'est pas une condition agréable, mais la certitude est absurde.

[kekekeks]

I've run benchmarks only on Linux, because I thought that it will be slow in windows anyways.

[gregoryyoung]

we have been poking around and havnt seen anything obvious

[eulerfx]

From write up on libevent2 IOCP:

A major rewrite was done for version 2 to support Windows IOCPs but anecdotal evidence suggests that it is still not working correctly.

Is this still valid?

[gregoryyoung]

When I tried to actually benchmark I got pretty crappy results. Could be a
problem with my benchmark but it ran great in linux

On Sat, May 17, 2014 at 6:31 PM, Lev Gorodinski notifications@github.comwrote:

From write up on libevent2 IOCP http://tinyclouds.org/iocp-links.html:

A major rewrite was done for version 2 to support Windows IOCPs but anecdotal
evidencehttp://www.mail-archive.com/libevent-users@monkey.org/msg01730.htmlsuggests that it is still not working correctly.

Is this still valid?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6#issuecomment-43409957
.

Studying for the Turing test