Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <47D4E4BC.1000706@rowe-clan.net>
Date: Mon, 10 Mar 2008 02:35:24 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: Obervation Apache 2.2.8 with Visual Studio 2008
References: <006901c87ef8$36c99970$0100a8c0@mother>
 <47CF13B9.1060107@rowe-clan.net> <000c01c88137$decf2180$0100a8c0@mother>
In-Reply-To: <000c01c88137$decf2180$0100a8c0@mother>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Steffen wrote:
> I noticed that here the memory used by httpd.exe is less when I comment 
> out:
> 
> #Win32DisableAcceptEx
> #EnableSendfile Off
> #EnableMMAP off

Yup; because those features aren't memory intensive; they actually save
memory (acceptex is atomic instead of several calls, sendfile means no
local file buffering, etc).

> Looks like  the use of AcceptEx()is no pain anymore.

ROFL.

It never was, until you use a buggy winsock layered provider who's authors
didn't think through all the API's (but developed by what they observed to
work for most apps).  So add in some bogus firewall/vpn/antispam filtering
and voila - TransmitFile (sendfile) or AcceptEx remain broke.

sendfile/TransmitFile semantics can also be suboptimal for serving content
off of network attached storage (e.g. another machine's share), and should
probably be turned off in that case (and must be turned off in the case
of some drivers, on a number of operating systems).

> Interesting new in VC9 is:
> The compiler contains tuning for the Intel Core microarchitecture during 
> code generation. This tuning is on by default and cannot be disabled as 
> it also helps Pentium 4 and other processors.

Hmmm... but it's tuning; you aren't locked into a specific processor?