RE: [users@httpd] performance prob due to httpd's piling up

Bennett Haselton <bennett@xxxxxxxxxxxxx> · Mon, 08 May 2006 00:35:00 -0700

I'm looking at http://httpd.apache.org/docs/2.0/install.html but it seems 

mainly aimed at people who are already very familiar with the system 

(indeed, who wouldn't need the information on that page).  The trouble is 

that if you're not familiar with it, then even a small omissions in the 

instructions can leave you lost.

For example, there's no section on recompiling a build that's already on 

your machine.  This is a dedicated Web server I'm leasing; do I even have 

the Apache sources on it already?  Where would I look?  So I take a guess 

that what I'm doing is most similar to "upgrading" (I'm just "upgrading" 

from one version to the same version).  One of the things it says to do is 

"find the file config.nice in the build directory of your installed 

server".  That's the first point on the page where the term "build 

directory" is used, and I don't know what it means.  (It apparently isn't 

/usr/sbin, the directory where httpd is located.)  So I search the hard 

drive to see if I can find one.  Meanwhile the instructions say that I 

should try the changed version by first installing it on "a different port 

(by adjusting the Listen directive)".  Now, by pure luck I know how to do 

that -- edit httpd.conf to change the "Listen" line.  But what if I didn't 

know that?  The page doesn't tell me.  Even though the word "Listen" is 

linked to a different page describing all the common directives, that page 

makes no mention of the httpd.conf file.  And, and, and...  I'm not asking 

for the answers to these specific questions, I'm just saying that the 

document requires a lot of external facts to be memorized already, and 

without those facts I'm blocked at every turn.

Is it possible to test the documentation the way they test the builds?  Get 

a group of volunteers who are decently smart but don't know much about 

UNIX, and have a bunch of them try out version 1, version 2, and version 3 

of the same document, and at the end you'll have data saying that 40% of 

readers of version 1 were able to complete it, 70% of readers of version 2, 

etc.

But meanwhile, given the documents that do exist, how much would it cost in 

today's market just to pay a UNIX guru to fix the Apache perf issue (up to 

the limits permitted by the hardware) and give it back when it's all 

done?  Hundreds of dollars, or thousands?  I'm hoping my ISP can do the 

recompile for example just for the cost of a $15 trouble ticket, because if 

they don't, the cost of fixing the problem goes way up...

At 01:14 AM 5/8/2006 -0500, Graham Frank wrote:

Just because the server completed the request properly doesn't mean that 

the

client didn't close properly.

Do you use a control panel on this server?  If so, check out the CP forums
for how to modify the Apache install.  If you do not use a control panel,
however, then recompile Apache the same way you did before but add
"--with-mpm=worker"

Be sure to check out http://httpd.apache.org for documentation on how to
configure the worker MPM.

--Graham

-----Original Message-----
From: Bennett Haselton [mailto:bennett@xxxxxxxxxxxxx]
Sent: Monday, May 08, 2006 12:29 AM
To: users@xxxxxxxxxxxxxxxx
Subject: Re: [users@httpd] performance prob due to httpd's piling up

Are there any instructions on this that are known to have worked
successfully in the past for people who are reasonably good at following
directions but don't know much about UNIX? :)

I lost over a month trying to get mod_perl installed because in every set
of instructions that I found on the Web, every step -- no, I'm not
exaggerating, *every step* in *every set of instructions* -- contained
errors or omissions, and I had to post to a forum or write to my ISP
practically very time.  There are too many examples to list, but the most

straightforward one was: all the instructions pages said that mod_perl 1.x 

worked only with Apache 1.x and mod_perl 2.x worked only with Apache 2.x,
so I lost a day hitting dead ends with 1.99x before finding out that
mod_perl 1.99x is "counted as" a 2.x version.

I'd be surprised if the reason all those extra httpd processes were still

running was because the clients didn't exit properly, because when running 

the stress test, "ab" reports on the number of successful and failed

requests.  If all the requests are successful (and they almost always 

are),

I'd assume that means the client got back a complete response from the
server, after which the server can close the connection.

         -Bennett

At 12:07 AM 5/8/2006 -0500, Graham Frank wrote:
>Eek!  Missed the second part of the post.
>
>Webalizer is used to parse the logs.
>
>Processes that don't exit might be stuck because the client didn't exit
>properly.
>

>You might want to check out using the WORKER mpm.  It might handle 

Apache

>in a way better to your liking.
>
>--Graham
>
>-----Original Message-----
>
>From:  Bennett Haselton <bennett@xxxxxxxxxxxxx>
>Subj:  Re: [users@httpd] performance prob due to httpd's piling up
>Date:  Sun May 7, 2006 11:55 pm
>Size:  3K
>To:  users@xxxxxxxxxxxxxxxx
>
>Apache/2.0.52, CentOS 4, Dell Pentium 4 3.0 GHZ, 1 GB RAM.
>
>Right now the output is:
>  >>>
>[root@server1 ~]# free -m
>               total       used       free     shared    buffers
> cached

>Mem:          1009        993         15          0          0 

10

>-/+ buffers/cache:        982         26
>Swap:         2047       1672        374
>  >>>
>
>but I think that's because a process called webalizer is running which
>must
>be what they use to parse the day's logs.
>

>So is there a reason those extra instances of httpd keep hanging around 

in

>
>memory when there's nothing left for them to do, and would it increase
>performance if I could make them go away?
>
>          -Bennett
>
>At 11:39 PM 5/7/2006 -0500, Graham Frank wrote:
> >Hey,
> >

> >What OS?  What version of Apache?  Could you show us an output of 

"free

> >-m"?.  What are the server specs?
> >
> >--Graham
> >
> >-----Original Message-----
> >
> >From:  Bennett Haselton <bennett@xxxxxxxxxxxxx>
> >Subj:  [users@httpd] performance prob due to httpd's piling up
> >Date:  Sun May 7, 2006 11:24 pm
> >Size:  1K
> >To:  users@xxxxxxxxxxxxxxxx
> >
> >I was running a stress test on a site that I run called
> >StupidCensorship.com which frequently slows to a crawl due to high
> >traffic.  From running a stress test on it using "ab" that sent 1,000
> >concurrent requests to the site, I found that the number of running

> >instances of /usr/sbin/httpd would rise from its initial default 

number

> of
> >
> >22, up to 258, and then stay steady at 258.  While the number was
> between

> >22 and 258, the site performance was still OK, but once it hit 258, 

the

> >response time was a lot slower.  I'm guessing this has something to do
> >with

> >the fact that while the number is climbing, the machine can just spawn 

a

> >new instance of httpd to handle the request, but once it hits the
> maximum
> >(due to hardware limits, I guess), new requests just get queued.
> >
> >Do these symptoms suggest any obvious way to improve performance,
> besides
> >getting more RAM?  (And even more RAM would, I assume, only raise the
> >limit

> >of "httpd" instances that could run, but it would still plateau once 

it

> >hit
> >that limit.)
> >

> >One possibility: I noticed that even after the stress test was over, 

the

> >number of running 'httpd' instances would fall very slowly, about one
> per
> >second, until it got back down to 22.  I thought they were keeping the

> >connection open, but my httpd.conf has KeepAlive set to Off.  If I 

could

> >somehow get the httpd instances to just exit memory once they were 

done,

> >instead of hanging around, would that solve the performance problem
> >without
> >any negative side effects?
> >
> >         -Bennett
> >
> >bennett@xxxxxxxxxxxxx     http://www.peacefire.org
> >(425) 497 9002
> >
> >
> >---------------------------------------------------------------------
> >The official User-To-User support forum of the Apache HTTP Server
> Project.
> >See <URL:http://httpd.apache.org/userslist.html> for more info.
> >To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
> >    "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
> >For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
> >
> >
> >
> >
> >
> >---------------------------------------------------------------------
> >The official User-To-User support forum of the Apache HTTP Server
> Project.
>
>
>--- message truncated ---
>
>
>
>---------------------------------------------------------------------

>The official User-To-User support forum of the Apache HTTP Server 

Project.

>See <URL:http://httpd.apache.org/userslist.html> for more info.
>To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
>    "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
>For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
   "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
   "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
  "   from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx