On Sun, 2012-02-05 at 15:40 -0500, Albert wrote: > Robert, > > I didn't see my request on your list. I was hoping that when a > Session directive is not provided, and random back-end selection is > used, pound would try to re-use back-end for requests made on HTTP > keep-alive connection. For example, if a client makes a request for a > web page, and then subsequent requests for images/css/js, I'd like to > have an option to tell pound to reuse the original backend on its > original connection (for that client's request). Currently, when the > subsequent requests come in, pound randomly selects a new backend. If > its a different back-end, it disconnects, and connects to the new > machine, and continues this cycle (where the original backend might be > chosen again). For this reason, to cut down on the number of > connects/disconnects, we use IP Session type, to "bind" a client's > request to a specific server. This leads to other problems, like > worse distribution, as randomness is now based on the client's IP > addresses.
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. > Also, this week we've been dealing with a client who claims they've > made requests to us, but I couldn't account for them. After looking > in log files for specific time of the request, I found the errors in > our LOG_NOTICE log file. Client's IP address wasn't logged, and > because it was a POST, it was difficult to find the request. > > I'd like to see better error reporting. If pound encounters a problem > with a backend during a transaction, it logs a message in LOG_NOTICE, > and doesn't log the response like it would after a normal response. > This leads to problems when a client reports an error, but the request > can't be found in normal log files. > > I'd like to see couple of improvements in this area: > 1. Better/consistent information logged for the error in LOG_NOTICE - > perhaps all of the fields covered by regular logging (LogLevel=1) plus > the error message. > 2. Log the response in LOG_INFO. This is very important, as it would > make sure all of the requests are account for in the log files. 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. -- Robert Segall Apsis GmbH Postfach, Uetikon am See, CH-8707 Tel: +41-32-512 30 19 -- To unsubscribe send an email with subject unsubscribe to [email protected]. Please contact [email protected] for questions.
