No news from here too. Complaints from the Win community are growing.
Tried some other servers like nginx, sambar, iis and no one gives AcceptEx
failed like errors or I have to do some like Win32DisableAcceptEx or
AcceptFilter none.
Running now iis in front of Apache and, for me it runs the best to get
reliable and fast networking.
IIS https.sys is a way back discussed here and the user list.
An interesting note from bill, Date: 2009-03-05 20:16:02
Perhap Apache on Windows needs to have patches offered. HTTP.SYS
is an interesting technology and certainly fits the profile for
an entirely separate MPM and core network stack, unrelated to the
conventional httpd server. Several folks have kicked around the
idea, but this is OPEN SOURCE SOFTWARE. Until someone feels like
doing to the work, it won't exist, and trolling doesn't encourage
solutions in open source.
On that friendly note; I happen to actually be deep inside of the
Windows (*socket based*) MPM, and the Apache 2.3-alpha MPM now
handles AcceptEx + Data (retrieving first packets optimization),
along with a better/more effective 'classic' solution for accept
based on WSAEventSelect(). It's already proven significantly
faster in my initial tests, although I'm not seeing any big win
from the change to accepting the initial data. We'll see how
that evolves, there are still two more performance changes I'm
designing into those listen/accept threads.
Bill
-----Original Message-----
From: William A. Rowe Jr.
Sent: Monday, May 07, 2012 10:12 PM Newsgroups: gmane.comp.apache.devel
To: dev@httpd.apache.org
Cc: Jim Jagielski
Subject: Re: Status of Windows-work for 2.4.x
On 5/3/2012 8:47 AM, Jim Jagielski wrote:
I'm curious what the status of 2.4.x-on-Windows is... What else
can we do to speed this along?
Can't speak for anyone but myself; I am just recovering from a month of
changing machines
over and over again due to a dead critical/primary laptop. Now that I have
two (impressed
with the evolution of the Dell E6420, but absolutely wow'ed by the newest
Sony SE series,
except for its two cores not four, and a sort-of-icky chicklet keyboard) I
stand a chance
of now messing around with 2.4 branch and trunk once again.
I'm thinking of a simple patch; in -D APR_SOCKET_DEBUG build of apr,
assert() on a recheck
of every on apr_os_sock_make(). If you inject a socket with ioctl flags in
the wrong
default mode, it should just freak out. This wouldn't be a release flag, of
course but
should get us to the bottom of this flaw.
