...But with that kind of traffic, I kinda wonder if you shouldn't
segment if possible.  I.e. run PHP or whatever with Prefork on one set
of servers and run mod_proxy+worker on the other...

On Wed, Feb 23, 2011 at 10:56 AM, "Plüm, Rüdiger, VF-Group"
<[email protected]> wrote:
>
>
>> -----Original Message-----
>> From: Jim Jagielski [mailto:[email protected]]
>> Sent: Mittwoch, 23. Februar 2011 16:50
>> To: [email protected]
>> Subject: Re: Bug 50807 - mod_proxy issue with half-closed connections
>>
>>
>> On Feb 23, 2011, at 10:35 AM, Eric Covener wrote:
>>
>> > On Wed, Feb 23, 2011 at 10:12 AM, Gregory Boyce
>> <[email protected]> wrote:
>
>> > The manual could certainly do a better job of describing how the
>> > connection pool is used, with respect to frontend
>> connections (is this
>> > a 2.0 thing only?), child processes, exactly when smax/ttl
>> is checked,
>> > etc.
>> >
>> > Surprising that you managed to burn through all your local ports but
>> > still not managed to trigger that backend connection closure being
>> > noticed -- maybe would make sense with prefork if the pools were
>> > per-process?
>> >
>> > You could also set MaxRequestsPerChild 100k for relief if this is
>> > still a problem.
>> >
>>
>> couldn't one also use lower level tcp stack tuning to
>> address this?
>>
>
> Not sure. The problem is that we (httpd) do not call a close on the socket
> descriptor. We only do that once we want to reuse the connection and notice
> that it has been closed by the remote side.
> So I am not sure if there is any TCP parameter that times out TCP connections
> in half open state and closes them on behalf of the application.
>
>
> Regards
>
> Rüdiger
>

Reply via email to