Date: Wed, 15 Feb 2006 16:41:16 +0000 From: BSD <bsdlists@celeritystorm.com> To: "Mark J. Nernberg" <mark.nernberg@1fast.us>, freebsd-apache@freebsd.org Subject: Re: Apache 1.3 + PHP 5 on FreeBSD 6 -- bad performance under load Message-ID: <43F359AC.3000304@celeritystorm.com> In-Reply-To: <C018BEBE.DF06%mark.nernberg@1fast.us> References: <C018BEBE.DF06%mark.nernberg@1fast.us>
next in thread | previous in thread | raw e-mail | index | archive | help
Nope: Mem: 921M Active, 699M Inact, 290M Wired, 96K Cache, 199M Buf, 2041M Free Swap: 4096M Total, 4096M Free Mark J. Nernberg wrote: >Is it swapping? > > >On 2/15/06 11:15 AM, "BSD" <bsdlists@celeritystorm.com> wrote: > > > >>Hello list, >> >>I've been having trouble identifying what's causing my apache server to >>take about 5 seconds to reply to new http requests. >> >>The machine in question is a Dual Xeon 2.8GHz with 4GB RAM, running >>apache 1.3.33_4 and PHP5 on 6.0-RELEASE-p4. It is a very busy PHP-based >>site. >> >>I have done a lot of tweaking on this server, but when the load goes a >>bit higher, it'll take about 5 seconds to answer to a standard GET / >>HTTP/1.1 via telnet (no PHP involved, since I'm not sending valid HTTP >>headers and it will reply with a 400 bad request). >> >>It is a problem with apache, as telnetting to the sshd port and hitting >>ENTER yields an instant "Protocol mismatch". -- no delay whatsoever. >> >>Both CPUs are around 65% idle after some PHP tweaks, so it's not CPU >>starvation either. >> >>I have accept filters enabled on the kernel, and apache is using them; also: >> >>options KVA_PAGES=768 >>options PMAP_SHPGPERPROC=5120 >> >>- to avoid that "colleting PV entries - suggest increasing >>PMAP_SHPGPERPROC". >> >>So far I've been unable to pinpoint what's causing apache a ~5 sec delay >>to process the GET. A timestamped tcpdump shows the following: >> >>Establishing the connection: >>02/15/2006 16:06:44.232973 192.168.0.1.53578 > APACHE_SERVER.80: S >>3958791824:3958791824(0) win 65535 <mss 1460,nop,wscale >>1,nop,nop,timestamp 7596496 0> (DF) [tos 0x10] >>02/15/2006 16:06:44.387141 APACHE_SERVER.80 > 192.168.0.1.53578: S >>2261546731:2261546731(0) ack 3958791825 win 65535 <mss 1460,nop,wscale >>2,nop,nop,timestamp 1124627170 7596496> (DF) >>02/15/2006 16:06:44.387348 192.168.0.1.53578 > APACHE_SERVER.80: . ack 1 >>win 33304 <nop,nop,timestamp 7596512 1124627170> (DF) [tos 0x10] >> >>02/15/2006 16:06:44.536819 APACHE_SERVER.80 > 192.168.0.1.53578: . ack 1 >>win 32942 <nop,nop,timestamp 1124627318 7596512> (DF) >> >> >>GET: (note: delay from previous step was induced by manually switching >>terminals and typing) >>02/15/2006 16:06:49.148143 192.168.0.1.53578 > APACHE_SERVER.80: P >>1:17(16) ack 1 win 33304 <nop,nop,timestamp 7596988 1124627318> (DF) >>[tos 0x10] >>02/15/2006 16:06:49.395079 APACHE_SERVER.80 > 192.168.0.1.53578: . ack >>17 win 32938 <nop,nop,timestamp 1124632177 7596988> (DF) >>02/15/2006 16:06:49.395284 192.168.0.1.53578 > APACHE_SERVER.80: P >>17:19(2) ack 1 win 33304 <nop,nop,timestamp 7597013 1124632177> (DF) >>[tos 0x10] >>02/15/2006 16:06:49.642127 APACHE_SERVER.80 > 192.168.0.1.53578: . ack >>19 win 32937 <nop,nop,timestamp 1124632423 7597013> (DF) >> >> >>"400 bad request" reply: >>02/15/2006 16:06:59.769277 APACHE_SERVER.80 > 192.168.0.1.53578: P >>1:481(480) ack 19 win 32942 <nop,nop,timestamp 1124642548 7597013> (DF) >>02/15/2006 16:06:59.769453 APACHE_SERVER.80 > 192.168.0.1.53578: F >>481:481(0) ack 19 win 32942 <nop,nop,timestamp 1124642548 7597013> (DF) >>02/15/2006 16:06:59.769543 192.168.0.1.53578 > APACHE_SERVER.80: . ack >>482 win 33064 <nop,nop,timestamp 7598050 1124642548> (DF) [tos 0x10] >>02/15/2006 16:06:59.770548 192.168.0.1.53578 > APACHE_SERVER.80: F >>19:19(0) ack 482 win 33304 <nop,nop,timestamp 7598050 1124642548> (DF) >>[tos 0x10] >>02/15/2006 16:06:59.923720 APACHE_SERVER.80 > 192.168.0.1.53578: . ack >>20 win 32941 <nop,nop,timestamp 1124642703 7598050> (DF) >> >> >>As you can see, it took 10 seconds to reply to the GET, yet the >>accepting of the connection was instant. >>I have more than enough maxfiles, maxproc, maxfilesperproc, nmbclusters >>etc. I guess the connection is so promptly answered because of the http >>accept filters built in the kernel. >> >>As a final note, the MaxClients I'm using are not nearly enough (around >>200 connections/second, according to pfstat graphics vs MaxClients 98). >>The reason for this is that trying to match MaxClients with the real >>load resulted in two 0.0% idle processors, since the PHP code is a bit >>heavy. I've opted to disable KeepAlive and lower MaxClients instead. >>Could this be the delay I'm seeing ? I think so, but I need more >>opinions, so feel free to reply. >> >> >>_______________________________________________ >>freebsd-apache@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-apache >>To unsubscribe, send any mail to "freebsd-apache-unsubscribe@freebsd.org" >> >> >> >> > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43F359AC.3000304>