> When possible, Pound avoids closing connections. If the client uses
> HTTP/1.1 Pound will open a new connection only if it has no other
> choice. This includes keep-alive. The session mechanism has priority.
This is not always the case. If Session directive is not used, then
pound tries to get a random backend (with priority values used to
determine randomness). If the backend is the same, then it'll reuse it,
otherwise, it'll close the connection to the first backend, and open a
new connection to the second backend. Here's an example:
Lets say you have something like this in the config file:
Service
BackEnd
Address backend1
Port 80
End
BackEnd
Address backend2
Port 80
End
End
request comes in to index.html (with HTTP/1.1 & keep-alive), which also
has image1.gif and image2.gif. Pound will randomly select a machine
from the list, lets say backend1, and request index.html, and send back
the response to client. The client will then make a request to
image1.gif, at which point pound will call get_backend(), and since
SESS_NONE is the session type, it will randomly select a backend. Now,
if the backend1 is selected, then you're correct, connection is not
closed. But if backend2 is selected, then backend1 connection is
closed, a new connection is opened to backend2. This cycle will repeat
for image2.gif.
The only way to avoid this, is to use some sort of Session Type, and we
use IP type. This forces pound to "bind" requests from specific IP
address to specific backend. This keeps the number of open/close
connections to the minimum. However, I'd like to avoid using Session
Type altogether, to get a more even distribution of requests to our
backends.
The other side effect of using Session, is when a connection to backend
fails (if the backend just died), you have a retry mechanism to go to
another machine. But it doesn't really work if HAPort is defined. In
such case, get_backend() call will return the same machine (remember its
IP session bound), and the retry to the same backend will fail again.
> What is logged to which file is a function of how you configure your
> syslog. Nothing prevents you from writing NOTICE and INFO to the same
> file, or writing the same message to more than one file. I'll add
> "expanded error details" to the list, but this is not always possible.
> To be checked.
Its not an issue of logging into different files. The issue is that a
response to the client is not logged in INFO log on an error condition.
Basically, anytime err_reply() is called, the response is sent back with
some HTTP code (either 414,500,501, or 503). From client's and pound's
perspective, the request was serviced with a response. But the response
itself is not logged in INFO log. My preference would be to add all of
the fields applicable to the LOG_LEVEL selected, and I understand that
some of them might not be available, depending on the error location.
If this is very difficult to do, and I'd like to see consistent
LOG_NOTICE messages, with the following fields: Client's IP address,
request (if available), HTTP code response, backend IP (if available),
and error description. A good example, is copy_bin() failure is logged
differently depending on where the failure occurred.
Albert
--
To unsubscribe send an email with subject unsubscribe to [email protected].
Please contact [email protected] for questions.
