Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Subject: Re: httpd 2.4.25, mpm_event, ssl: segfaults
To: dev@httpd.apache.org
References: <alpine.GSO.2.20.1702011839170.17193@hatchepsut.acc.umu.se>
 <CAKQ1sVOMeQtb6=w3+FTzt2YE5OWOuzObbXWBUvfu73JLVkW6Bw@mail.gmail.com>
 <eb0b375f-6ad2-fbb0-cb2d-2a17a03c46ee@gmail.com>
 <CAKQ1sVMXRG2n2CuNiOWWW6oha+HEsTMC3bnOjNvR4WL4G_PvVw@mail.gmail.com>
 <0a787764-e1ac-88e4-9b26-92d91bdd5d72@gmail.com>
 <CAKQ1sVM=6mzFAZ+g1t-gFrfKo4PE1S0vGR8s=YQeapmBmcdQ2Q@mail.gmail.com>
 <75f8913a-d874-e2c8-d5f5-c917cf236c1e@gmail.com>
 <alpine.GSO.2.20.1702030900470.23400@hatchepsut.acc.umu.se>
 <alpine.GSO.2.20.1702030922530.23400@hatchepsut.acc.umu.se>
 <8003d8ac-0451-8149-4560-3a0210fc1507@gmail.com>
 <alpine.GSO.2.20.1702071111071.3839@hatchepsut.acc.umu.se>
From: Jacob Champion <champion.p@gmail.com>
Message-ID: <221b43e3-59b4-4a87-e731-c528f3c1e0de@gmail.com>
Date: Wed, 15 Feb 2017 12:50:33 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.GSO.2.20.1702071111071.3839@hatchepsut.acc.umu.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Wed, 15 Feb 2017 20:50:41 -0000

On 02/07/2017 02:32 AM, Niklas Edmundsson wrote:
> O_DIRECT also bypasses any read-ahead logic, so you'll have to do nice
> and big IO etc to get good performance.

Yep, confirmed... my naive approach to O_DIRECT, which reads from the 
file in the 8K chunks we're used to from the file bucket brigade, 
absolutely mutilates our performance (80% slowdown) *and* rails the disk 
during the load test. Not good.

(I was hoping that combining the O_DIRECT approach with in-memory 
caching would give us the best of both worlds. Nope. A plain read() with 
no explicit caching at all is much, much faster on my machine.)

> We've played around with O_DIRECT to optimize the caching process in our
> large-file caching module (our backing store is nfs). However, since all
> our hosts are running Linux we had much better results with doing plain
> reads and utilizing posix_fadvise with POSIX_FADV_WILLNEED to trigger
> read-ahead and POSIX_FADV_DONTNEED to drop the original file from cache
> when read (as future requests will be served from local disk cache).
> We're doing 8MB fadvise chunks to get full streaming performance when
> caching large files.

Hmm, I will keep the file advisory API in the back of my head, thanks 
for that.

For the next step, I want to find out why TLS connections see such a big 
performance hit when I switch off mmap(), but unencrypted connections 
don't... it's such a huge difference that I feel like I must be missing 
something obvious.

--Jacob