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