knitti wrote:
On 12/12/07, Daniel Ouellet <[EMAIL PROTECTED]> wrote:
I am only
saying that using PF in front of httpd will reduce the possible number
of httpd close_wait you might see. By default httpd can only support up
to 256 connections, unless you increase it and compile it again.
I don't understand why pf would reduce this. Every single CLOSE_WAIT
stems from a former established connection, and pf can nothing do
to convince httpd to close its socket. No rogue clients involved here.
Yes you are right.
lead you in that path, then I am sorry. What will affect your close_wait
time (when you reach that point) are the tcp stack value, witch I am
reluctant to suggest to adjust as they sure can create way more harm
then goods.
I don't think there is a systl for that. TCP connections don't expire by
default, if you not make them, and the same should go for a half-closed
one. There are perfectly legit reasons for long open half-closed
TCP connections.
In my flow of emails, I mixed two things. Glad you cut it. It would help
for normal heavy traffic, or fake one and it's possible to affect the
keep alive from the tcp side making sockets be available sooner, etc.
But again, specifically for CLOSE_WAIT, I stand corrected.
My point with PF here was that it would reduce the possible numbers of
close_wait state you could possibly see in the first place, witch is one
of the original goal of the question.
Why?
I miss spoke ( or in this case write ) I confuse myself between that
stage and idle/waiting/FIN_WAIT_x/etc of fake connections that would
take sockets of httpd away from legit traffic that PF would/could
definitely help, however, in this tread, I lost track of where we were
in the process and specially, I had a gap in my understanding that miss
lead me as well.
Was interesting however.
Thanks
Daniel
