On Mon, 2005-10-31 at 12:03 -0500, Scott Ullrich wrote: > Please describe the hardware your using fully. NICS, etc. This is > not normal behavior.
Sure It is Dell Poweredge 750 512MB RAM, SATA150 disk, Celeron 2.4Ghz ACPI APIC Table: <DELL PE750 > Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 2.40GHz (2400.10-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x4400<CNTX-ID,<b14>> real memory = 536608768 (511 MB) avail memory = 515547136 (491 MB) Nics are build in Intel 10/100/1000 NICs: em0: <Intel(R) PRO/1000 Network Connection, Version - 2.1.7> port 0xece0-0xecff mem 0xfe1e0000-0xfe1fffff irq 18 at device 1.0 on pci1 em0: Ethernet address: 00:14:22:0a:64:4c em0: Speed:N/A Duplex:N/A It does not looks like this is hardware issue for me as if I disable firewall it works fine. I tried turning off scrub and it does not change anything. Still timeout after few requests: [EMAIL PROTECTED]:/tmp> ./ab2 -n 100000 http://111.111.111.158/ This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0 Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/ Benchmarking 111.111.111.158 (be patient) Completed 10000 requests apr_poll: The timeout specified has expired (70007) > > On 10/31/05, Peter Zaitsev <[EMAIL PROTECTED]> wrote: > > 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] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
