I guess I agree, if I am not running the script on the web-server, top is
useless.
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(a)googlemail.com> 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 ?
Paulo
On 12/7/06, Dennis Gilmore <dennis(a)ausil.us> 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(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
>
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list