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
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. 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? 4- All ab output is recorded for future analysis 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
On 12/6/06, Ahmed Kamal email.ahmedkamal@googlemail.com 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
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. 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? 4- All ab output is recorded for future analysis 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
Thanks for sending this out Ahmed, you and Paulo have been doing a great job with all of this. Before we get started I'm hoping to get cacti set up for a good baseline. One thing I'd like to note to the rest of the list is that paulo and ahmed are both timezoned around GMT, so they can do this easily during off hours as not to cause a disruption.
-Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I need to know well in advance of any thing that will "stress test" systems on the 209.132.176.0/23 network.
I want to ensure the LB can handle it.
Note, incoming BW can exceed 2 Gb/s to the systems in the Red Hat DC.
Thanks
Mike McGrath wrote:
On 12/6/06, Ahmed Kamal email.ahmedkamal@googlemail.com 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
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. 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? 4- All ab output is recorded for future analysis 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
Thanks for sending this out Ahmed, you and Paulo have been doing a great job with all of this. Before we get started I'm hoping to get cacti set up for a good baseline. One thing I'd like to note to the rest of the list is that paulo and ahmed are both timezoned around GMT, so they can do this easily during off hours as not to cause a disruption.
-Mike
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
- -- ======================================================== = Stacy J. Brandenburg Red Hat Inc. = = Manager, Network Operations sbranden@redhat.com = = 919-754-4313 http://www.redhat.com = ========================================================
Fingerprint 03F7 43BE 1150 CCFA F57B 54DD AEDB 1C27 1828 D94D
On 12/6/06, Stacy J. Brandenburg sbranden@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I need to know well in advance of any thing that will "stress test" systems on the 209.132.176.0/23 network.
No problem, we'll be fully coordinating this with everyone.
-Mike
On Wed, 2006-12-06 at 18:02 -0600, Mike McGrath wrote:
Before we get started I'm hoping to get cacti set up for a good baseline.
Not to denigrate Cacti but you might want to take a look at Zabbix... It was recently included in FE (I did the review). It's a little bit trickier to set up but the polling is done using a server & agent written in C, as opposed to Cacti which is largely PHP. I've been working on a Zabbix install at work and I poll a number of variables every 5 sec.
Jeff
On Wed, 2006-12-06 at 21:07 -0600, Jeffrey C. Ollie wrote:
On Wed, 2006-12-06 at 18:02 -0600, Mike McGrath wrote:
Before we get started I'm hoping to get cacti set up for a good baseline.
Not to denigrate Cacti but you might want to take a look at Zabbix... It was recently included in FE (I did the review). It's a little bit trickier to set up but the polling is done using a server & agent written in C, as opposed to Cacti which is largely PHP. I've been working on a Zabbix install at work and I poll a number of variables every 5 sec.
cacti in php doesn't matter. It's the snmp interface in cacti which does the tricks and that's all done using snmp libs. It also has the advantage of just being another use of snmp instead of being it's own whole thing.
-sv
seth vidal wrote:
On Wed, 2006-12-06 at 21:07 -0600, Jeffrey C. Ollie wrote:
On Wed, 2006-12-06 at 18:02 -0600, Mike McGrath wrote:
Before we get started I'm hoping to get cacti set up for a good baseline.
Not to denigrate Cacti but you might want to take a look at Zabbix... It was recently included in FE (I did the review). It's a little bit trickier to set up but the polling is done using a server & agent written in C, as opposed to Cacti which is largely PHP. I've been working on a Zabbix install at work and I poll a number of variables every 5 sec.
cacti in php doesn't matter. It's the snmp interface in cacti which does the tricks and that's all done using snmp libs. It also has the advantage of just being another use of snmp instead of being it's own whole thing.
ZABBIX also uses the snmp-libs for the optional SNMP agents. I use ZABBIX to monitor all of my servers and it suits me pretty nicely. The ZABBIX web frontend is in PHP, just like Cacti's. See http:// www.zabbix.com/manual/v1.1/install_requirements_software.php for more info on the software requirements for ZABBIX.
Nils Breunese.
Hi,
1- A script was written which uses apache's ab tool to stress the server. Script will run on the web-server host.
There is a tool available for benchmarking apache called: ab or ab2 which is apache benchmark to use it you simply issue:
./ab -n 1000 -c 100 http://www.fedoraproject.org/wiki/index.htm
The above will simulate 100 users accessing the website 1000 times
On 07/12/06, Nils Breunese nils@breun.nl wrote:
seth vidal wrote:
On Wed, 2006-12-06 at 21:07 -0600, Jeffrey C. Ollie wrote:
On Wed, 2006-12-06 at 18:02 -0600, Mike McGrath wrote:
Before we get started I'm hoping to get cacti set up for a good baseline.
Not to denigrate Cacti but you might want to take a look at Zabbix... It was recently included in FE (I did the review). It's a little bit trickier to set up but the polling is done using a server & agent written in C, as opposed to Cacti which is largely PHP. I've been working on a Zabbix install at work and I poll a number of variables every 5 sec.
cacti in php doesn't matter. It's the snmp interface in cacti which does the tricks and that's all done using snmp libs. It also has the advantage of just being another use of snmp instead of being it's own whole thing.
ZABBIX also uses the snmp-libs for the optional SNMP agents. I use ZABBIX to monitor all of my servers and it suits me pretty nicely. The ZABBIX web frontend is in PHP, just like Cacti's. See http:// www.zabbix.com/manual/v1.1/install_requirements_software.php for more info on the software requirements for ZABBIX.
Nils Breunese.
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Hi Damian,
The script written by Ahmed, already uses ab. He is using the script to gather some other information, besides the ab output. Please take a look into webtorture.sh, and you'll see what i mean.
Paulo
On 12/7/06, Damian Myerscough damian.myerscough@gmail.com wrote:
Hi,
1- A script was written which uses apache's ab tool to stress the
server. Script will run on the web-server host.
There is a tool available for benchmarking apache called: ab or ab2 which is apache benchmark to use it you simply issue:
./ab -n 1000 -c 100 http://www.fedoraproject.org/wiki/index.htm
The above will simulate 100 users accessing the website 1000 times
On 07/12/06, Nils Breunese nils@breun.nl wrote:
seth vidal wrote:
On Wed, 2006-12-06 at 21:07 -0600, Jeffrey C. Ollie wrote:
On Wed, 2006-12-06 at 18:02 -0600, Mike McGrath wrote:
Before we get started I'm hoping to get cacti set up for a good baseline.
Not to denigrate Cacti but you might want to take a look at Zabbix... It was recently included in FE (I did the review). It's a little bit trickier to set up but the polling is done using a server & agent written in C, as opposed to Cacti which is largely PHP. I've been working on a Zabbix install at work and I poll a number of variables every 5 sec.
cacti in php doesn't matter. It's the snmp interface in cacti which does the tricks and that's all done using snmp libs. It also has the advantage of just being another use of snmp instead of being it's own whole thing.
ZABBIX also uses the snmp-libs for the optional SNMP agents. I use ZABBIX to monitor all of my servers and it suits me pretty nicely. The ZABBIX web frontend is in PHP, just like Cacti's. See http:// www.zabbix.com/manual/v1.1/install_requirements_software.php for more info on the software requirements for ZABBIX.
Nils Breunese.
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
ok.
On 07/12/06, Paulo Santos paulo.banon@googlemail.com wrote:
Hi Damian,
The script written by Ahmed, already uses ab. He is using the script to gather some other information, besides the ab output. Please take a look into webtorture.sh, and you'll see what i mean.
Paulo
On 12/7/06, Damian Myerscough damian.myerscough@gmail.com wrote:
Hi,
1- A script was written which uses apache's ab tool to stress the
server. Script will run on the web-server host.
There is a tool available for benchmarking apache called: ab or ab2 which is apache benchmark to use it you simply issue:
./ab -n 1000 -c 100
http://www.fedoraproject.org/wiki/index.htm
The above will simulate 100 users accessing the website 1000 times
On 07/12/06, Nils Breunese < nils@breun.nl> wrote:
seth vidal wrote:
On Wed, 2006-12-06 at 21:07 -0600, Jeffrey C. Ollie wrote:
On Wed, 2006-12-06 at 18:02 -0600, Mike McGrath wrote:
Before we get started I'm hoping to get cacti set up for a good baseline.
Not to denigrate Cacti but you might want to take a look at Zabbix... It was recently included in FE (I did the review). It's a little bit trickier to set up but the polling is done using a server & agent written in C, as opposed to Cacti which is largely PHP. I've been working on a Zabbix install at work and I poll a number of variables every 5 sec.
cacti in php doesn't matter. It's the snmp interface in cacti which does the tricks and that's all done using snmp libs. It also has the advantage of just being another use of snmp instead of being it's own whole thing.
ZABBIX also uses the snmp-libs for the optional SNMP agents. I use ZABBIX to monitor all of my servers and it suits me pretty nicely. The ZABBIX web frontend is in PHP, just like Cacti's. See http://
www.zabbix.com/manual/v1.1/install_requirements_software.php for more
info on the software requirements for ZABBIX.
Nils Breunese.
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
AFAIK, cacti uses the php interface to net-snmp libs in their poller code, so they are a bit slower. For that they made another poller in C just for performance. http://www.cacti.net/cactid_info.php
Stacy, all tests planned will be on the LAN only. No incoming bandwidth will be used (not that I have the kind of bandwidth that would stress the servers anyway ;) Anyway, as Mike said, we will of course be co-ordinating with you.
Anyway, please let's dont let the thread slip into a Zabbix-vs-Cacti debate, since it's difficult to get a chance to stress test the servers, I hope to get all relevant information the first time. Kindly, do let me know your suggestions regarding: - Test setup/conditions - Interesting apache configuration options we might need to test under (currently no config sweeping is planned) - A kind of load monitoring tool we could/should use (other than "top")
Best Regards
On 12/7/06, Damian Myerscough damian.myerscough@gmail.com wrote:
ok.
On 07/12/06, Paulo Santos paulo.banon@googlemail.com wrote:
Hi Damian,
The script written by Ahmed, already uses ab. He is using the script to gather some other information, besides the ab output. Please take a look into webtorture.sh, and you'll see what i mean.
Paulo
On 12/7/06, Damian Myerscough damian.myerscough@gmail.com wrote:
Hi,
1- A script was written which uses apache's ab tool to stress the
server. Script will run on the web-server host.
There is a tool available for benchmarking apache called: ab or ab2 which is apache benchmark to use it you simply issue:
./ab -n 1000 -c 100
http://www.fedoraproject.org/wiki/index.htm
The above will simulate 100 users accessing the website 1000 times
On 07/12/06, Nils Breunese < nils@breun.nl> wrote:
seth vidal wrote:
On Wed, 2006-12-06 at 21:07 -0600, Jeffrey C. Ollie wrote:
On Wed, 2006-12-06 at 18:02 -0600, Mike McGrath wrote: > Before we get started I'm hoping to get > cacti set up for a good baseline.
Not to denigrate Cacti but you might want to take a look at Zabbix... It was recently included in FE (I did the review). It's a little
bit
trickier to set up but the polling is done using a server & agent written in C, as opposed to Cacti which is largely PHP. I've
been
working on a Zabbix install at work and I poll a number of
variables
every 5 sec.
cacti in php doesn't matter. It's the snmp interface in cacti
which
does the tricks and that's all done using snmp libs. It also has the advantage of just being another use of snmp instead of being it's
own
whole thing.
ZABBIX also uses the snmp-libs for the optional SNMP agents. I use ZABBIX to monitor all of my servers and it suits me pretty nicely. The ZABBIX web frontend is in PHP, just like Cacti's. See http://
www.zabbix.com/manual/v1.1/install_requirements_software.php for more
info on the software requirements for ZABBIX.
Nils Breunese.
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
On Thu, 2006-12-07 at 16:07 +0200, Ahmed Kamal wrote:
- A kind of load monitoring tool we could/should use (other than
"top")
If we could coordinate things with the crew at the hosting site, it would be interesting to capture all of the packets between the server and clients during the test. There are some tools in wireshark that would be useful for analyzing the results of the test. For best performance you'd want to have a separate system capturing traffic that was being mirrored by the switch. Second best would be to dump the packet captures to the web server's disk, but I would think that the I/O caused by that would affect the test.
Jeff
Please note that there will only be one client connecting to the web-server. I guess (if we can't get a separate dump machine), it would be better to dump on the client machine, than on the server machine where the disk will probably be active.
OTOH, I'm not sure what kind of information would be interesting to us from a packet dump in this case?
On 12/7/06, Jeffrey C. Ollie jeff@ocjtech.us wrote:
On Thu, 2006-12-07 at 16:07 +0200, Ahmed Kamal wrote:
- A kind of load monitoring tool we could/should use (other than
"top")
If we could coordinate things with the crew at the hosting site, it would be interesting to capture all of the packets between the server and clients during the test. There are some tools in wireshark that would be useful for analyzing the results of the test. For best performance you'd want to have a separate system capturing traffic that was being mirrored by the switch. Second best would be to dump the packet captures to the web server's disk, but I would think that the I/O caused by that would affect the test.
Jeff
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
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
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@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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
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@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@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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
On Thu, 2006-12-07 at 19:31 +0200, Ahmed Kamal wrote:
Does anyone know how fast cacti polls the server, we should need something < 5 sec I guess?
Cacti by default polls every 5 minutes. It's adjustable, but unfortunately the polling is controlled by cron so at best you could do 1 minute intervals.
Also, it would have been nice to get per process swap/ram info, guess cacti cant do that.
There's some stuff in the host resources SNMP mib that will show you the total amount of memory allocated to a process, but it isn't separated into separate resident/virtual set numbers.
Anyway, I can still launch one long-running top job as well as cacti.
Can't hurt...
Jeff
On 12/7/06, Ahmed Kamal email.ahmedkamal@googlemail.com wrote:
Are we ready to pick a date and time for the first test?
-Mike
I am ready from my side.
Paulo
On 12/13/06, Mike McGrath mmcgrath@fedoraproject.org wrote:
On 12/7/06, Ahmed Kamal email.ahmedkamal@googlemail.com wrote:
Are we ready to pick a date and time for the first test?
-Mike
Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
On 12/13/06, Paulo Santos paulo.banon@googlemail.com wrote:
I am ready from my side.
Paulo
Someone in IRC posted this link tonight. Its pretty useful -
http://www.ircache.net/cgi-bin/cacheability.py?query=http%3A%2F%2Ffedoraproj...
-Mike
Can we do some side-by-side comparisons with lighttpd whilst we're at it? It'd be trivial to do at the same time. I've had good experience with lighttpd in the past, and it's in extras already.
Generally I am ready. I'm just facing some problems with my ISP, so I'd like to wait a couple of days
On 12/13/06, Mike McGrath mmcgrath@fedoraproject.org wrote:
On 12/7/06, Ahmed Kamal email.ahmedkamal@googlemail.com wrote:
Are we ready to pick a date and time for the first test?
-Mike
On 12/14/06, Ahmed Kamal email.ahmedkamal@googlemail.com wrote:
Generally I am ready. I'm just facing some problems with my ISP, so I'd like to wait a couple of days
Works for me, can you pick a start time, end time, and date so we can get Stacy's approval?
-MIke
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
Changing the original plan. The script should run from a client host (not the web server). I think one client host is enough to hammer the server. Using multi-hosts will only complicate data gathering un-necessarily Serving static pages is waaay faster. Just try it on a wiki/cms style server. My 2Ghz CPU is at 100% just at 10 concurrent connections to joomla!
I had some that did not get captured for some reason (1900 and 2000) also i
was left with alot of top processes running
umm ok, will try to fix this
infrastructure@lists.fedoraproject.org