On Sun, 2005-10-30 at 23:14 +0100, Espen Johansen wrote: > Hi Peter, > > I have seen you have done a lot of testing with apache benchmarking. > I find it a little strange to use this as a test. Basically you will hit the > roof of standing I/O operations because you introduce latency with pfsense. > The lower the latency the more finished tasks/connections per time unit. > Most people don't take this into consideration when they tune apache. > Although, this is one of the most important aspects of web-server tuning.
Espen, If you would see to the set of my emails you would see the growing latency with network pooling is not my concern, as well as well as dropping throughput with pfsense in the middle - it is all understandable. What is NOT ok however is the stall (20+ seconds) when CPU usage on pfsense drops almost to zero and no traffics come on connections. Sometimes it causes apache benchmark to abort sometimes just shows crazy response times. This does not happen in direct benchmark (no pfsense in the middle) or with pfsense with disable firewall. Why I used apache benchmark ? Well it is simple stress test which results in a lot of traffic and a lot of states in the state tables. > > This is the scenario: > > Client with low BW and high latency will generate a standing I/O because of > the way apache is designed. So if a client with 100ms latency asks for a > file of 100Kbyte and he has a 3KB/s transfer rate he will generate a > standing I/O operation for "latency + transfer time", and the I/O operation > will not be finished until he has a completed transfer. So basically you do > the same, because you change the amount of time the request takes to process > you will have more standing I/O operations then if pfsense does routing only > (faster then routing and filtering). So lets say that you increase latency > from 0.4 ms to 2 ms it will mean that you have standing I/O 250% longer. So > in turn that will mean that your ability to serve connections will be 1/5 > with 2ms compared to 0.4 ms latency. Well... This would be the case in real life scenario - slow clients blowing up number of apache children. But it is not the case in synthetic Apache benchmark test. In this case you set fixed concurrency. I obviously set it low enough for my Apache box to handle. Furthermore pfsense locks even with single connection (this is independent if device pooling is enabled) > > The ones listed below seems to be the once that has the most effect on > polling and performance. You will have to play around with these settings to > find out what works best on your HW, as I can't seem to find some common > setting that works well for all kinds of HW. > > kern.polling.each_burst=80 > kern.polling.burst_max=1000 > kern.polling.user_frac=50 Thanks. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
