Bennet, just to give you some tips: - First: I assume you have root access on the server, if you don't, ask you ISP to solve this for you. - if you want to find a file on your machine, use 'locate <filename>'. If locate gives you an error, run updatedb, wait, and try again - If you ask questions on a mailing list as this *always* include the particular unix/linux version, distribution, because the experts on this list can give you much to-the-point advice. - understand that the apache docs are for the apache *as they distribute it* companies like RedHat, SuSE have their own way of doing things, and apache instructions only apply partially. Configuration file docs are ok though - I think a Unix/apache guru should be able to solve this problem in a couple of hours max. Ron Bennett Haselton schreef: > 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 > -- NeoNova BV, The Netherlands Professional internet and VoIP solutions http://www.neonova.nl Kruislaan 419 1098 VA Amsterdam info: 020-5628292 servicedesk: 020-5628292 fax: 020-5628291 The following disclaimer applies to this email: http://www.neonova.nl/maildisclaimer
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
|