I guess I agree, if I am not running the script on the web-server, top is useless.<br>Does anyone know how fast cacti polls the server, we should need something < 5 sec I guess?<br>Also, it would have been nice to get per process swap/ram info, guess cacti cant do that.
<br>Anyway, I can still launch one long-running top job as well as cacti.<br><br><div><span class="gmail_quote">On 12/7/06, <b class="gmail_sendername">Paulo Santos</b> <<a href="mailto:paulo.banon@googlemail.com">paulo.banon@googlemail.com
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Mike just deployed cacti on the folowing hosts:<br><br>- proxy1<br>- proxy2
<br>- app1<br>- app2<br><br>I think we can drop top for now. What you guys think ?<br><span class="sg"><br><br>Paulo</span><div><span class="e" id="q_10f5d8eea957fe54_2"><br><br><br><div><span class="gmail_quote">On 12/7/06,
<b class="gmail_sendername">Dennis Gilmore</b> <<a href="mailto:dennis@ausil.us" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">dennis@ausil.us</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wednesday 06 December 2006 16:43, Ahmed Kamal wrote:<br>> Hi,<br>> Due to the web server hit faced with FC6 release, some actions are being<br>> taken to minimize the chance of facing such issues again. One of the steps
<br>> is to stress test our web-server infrastructure to measure our current and<br>> future capabilities. I'd like to run some tests on fp.o web-server, please<br>> let me know your thoughts/comments. Here are some details.
<br>><br>> Test Targets:<br>><br>> 1- Measure our bare (no caching) maximum serving rate<br>> 2- Measure our cached serving rate, to assess the implemented caching<br>> efficiency<br>> 3- Gather numbers like (When do we get CPU saturated, RAM requirements ..).
<br>> Possibly draw graphs (everyone thinks graphs are cool), the numbers should<br>> help us base future calculations on a solid basis<br>> 4- Future: Possibly implement a mechanism to cap the maximum connected
<br>
> clients to a specific server, to the maximum it can handle gracefully, to<br>> avoid killing a server<br>I think this is great. I think to get things done right we will need to do it<br>in a distributed manner.<br>
<br>> Test Plan:<br>> 1- A script was written which uses apache's ab tool to stress the server.<br>> Script will run on the web-server host.<br>Is that a fair test? i tired the script on a box i have which while very
<br>different to the boxes in use i could not get it to break a sweat.<br>admittedly i was only serving the default welcome page. I will try it again<br>with a wiki setup and see how it goes then<br><br>> 2- The script fires a total number of connections equal to ten times the
<br>> maximum concurrency rate (to get good average, and avoid transients)<br>> 3- The concurrency rate is sweeped between 10 and 400 (my 1G-RAM machine<br>> swaps at about 100 connections)? any suggestions?<br>
i had up to 2000 connections in an effort to get thinks choked up and did it
<br>in steps of 100<br><br>> 4- All ab output is recorded for future analysis<br>I had some that did not get captured for some reason (1900 and 2000) also i<br>was left with alot of top processes running<br>> 5- A monitoring thread is fired before ab is launched. The monitoring uses
<br>> "top" to record load/cpu/ram/process information in log files as well<br>> 6- Tests are repeated with "ab -k" for enabling the HTTP keep-alive option.<br>> Not sure if this is needed, or if it will make much difference! comments?
<br>> 7- Tests are done once with caching enabled and one more time without<br>> caching<br>><br>> Please let me know your thoughts about the testing setup, should we be<br>> recording more data? should we be stressing the server in a different way,
<br>> should we be testing some apache config options ... etc ?<br>> Thanks<br><br>--<br>,-._|\ Dennis Gilmore, RHCE<br>/ \ Proud Australian<br>\_.--._/ | Aurora | Fedora |<br> v <br><br>_______________________________________________
<br>Fedora-infrastructure-list mailing list<br><a href="mailto:Fedora-infrastructure-list@redhat.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Fedora-infrastructure-list@redhat.com</a><br><a href="https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list</a><br></blockquote></div><br>
</span></div><br>_______________________________________________<br>Fedora-infrastructure-list mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:Fedora-infrastructure-list@redhat.com">
Fedora-infrastructure-list@redhat.com</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list" target="_blank">https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
</a><br><br><br></blockquote></div><br>