I'm not familiar with Horde, does it run against a database server ?, based on the information you provided, there's seems to be something else preventing the apache to serve the requests on time. On Tue, Sep 14, 2010 at 2:19 PM, Paras pradhan <pradhanparas@xxxxxxxxx> wrote: > Pablo, > Here the o/p: > command: ab -t 60 -c 100 https://domain/h/imp/login.php > > vmstat: > [root@wmail /]# vmstat -S M 2 20 > procs -----------memory---------- ---swap-- -----io---- --system-- > -----cpu------ > r b swpd free buff cache si so bi bo in cs us sy id > wa st > 40 0 0 7305 288 2259 0 0 0 3 14 11 2 1 97 > 0 0 > 7 0 0 7301 288 2259 0 0 0 0 1785 15462 39 15 46 > 0 0 > 47 0 0 7296 288 2259 0 0 0 0 1720 15032 40 17 43 > 0 0 > 25 0 0 7297 288 2260 0 0 0 62 1656 15157 40 15 45 > 0 0 > 7 0 0 7296 288 2260 0 0 0 0 1866 15701 40 17 44 > 0 0 > 51 1 0 7293 288 2260 0 0 0 42 1862 16083 37 14 44 > 4 0 > 1 0 0 7295 288 2260 0 0 0 12 1807 15293 42 15 42 > 0 0 > 51 0 0 7298 288 2260 0 0 0 0 1797 16015 36 14 50 > 0 0 > 14 1 0 7296 288 2260 0 0 0 54 1782 15001 42 15 41 > 2 0 > 36 0 0 7293 288 2260 0 0 0 220 1728 14567 43 16 37 > 3 0 > 17 0 0 7292 288 2260 0 0 0 42 1726 15443 40 16 44 > 0 0 > 11 0 0 7296 288 2260 0 0 0 10 1844 15618 39 14 46 > 0 0 > 9 0 0 7290 288 2260 0 0 0 0 1617 14694 41 15 44 > 0 0 > 4 0 0 7291 288 2260 0 0 0 44 1632 14668 42 15 43 > 0 0 > 7 0 0 7287 288 2260 0 0 0 16 1657 14941 38 17 45 > 0 0 > 14 1 0 7287 288 2260 0 0 0 40 1751 15042 39 17 41 > 3 0 > 43 0 0 7290 288 2260 0 0 0 12 1787 15635 38 18 44 > 0 0 > 1 0 0 7288 288 2260 0 0 0 0 1675 14830 41 17 42 > 0 0 > 44 0 0 7290 288 2260 0 0 0 44 1762 15691 33 16 51 > 0 0 > 39 0 0 7288 288 2260 0 0 0 10 1666 14491 41 18 40 > 1 0 > > Process waiting for run time (r) seems to be high. But don't know if it is > normal with 100 concurrent users. > Thanks > Paras. > > On Mon, Sep 13, 2010 at 7:11 PM, Pablo Garcia Melga <malevo@xxxxxxxxx> > wrote: >> >> Paras, have you checked the OS counters ?, is this completely CPU bound ? >> would you post a "vmstat 2" run during the ab testing ? >> >> Regards, Pablo >> >> On Mon, Sep 13, 2010 at 7:28 PM, Paras pradhan <pradhanparas@xxxxxxxxx> >> wrote: >> > I got almost the same result as yours with a small test php script. But >> > with >> > the login page of horde, I am getting a small number of requests >> > processed. >> > I am assuming my tuned apache is fine and its the bulky horde php >> > scripts >> > that are hitting me. But still looking around the solution.. I have >> > memcached and eaccelerator in place but not seeing improvements. >> > >> > With small php script: >> > nagarkot:~ ppradhan$ ab -t 10 -c 30 https://domain/test.php >> > This is ApacheBench, Version 2.3 <$Revision: 655654 $> >> > Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ >> > Licensed to The Apache Software Foundation, http://www.apache.org/ >> > Benchmarking hostname (be patient) >> > Finished 4608 requests >> > >> > Server Software: Apache/2.2.3 >> > Server Hostname: hostname >> > Server Port: 443 >> > SSL/TLS Protocol: TLSv1/SSLv3,AES256-SHA,1024,256 >> > Document Path: /test.php >> > Document Length: 68 bytes >> > Concurrency Level: 30 >> > Time taken for tests: 10.003 seconds >> > Complete requests: 4608 >> > Failed requests: 0 >> > Write errors: 0 >> > Total transferred: 1107432 bytes >> > HTML transferred: 313480 bytes >> > Requests per second: 460.65 [#/sec] (mean) >> > Time per request: 65.125 [ms] (mean) >> > Time per request: 2.171 [ms] (mean, across all concurrent >> > requests) >> > Transfer rate: 108.11 [Kbytes/sec] received >> > Connection Times (ms) >> > min mean[+/-sd] median max >> > Connect: 8 30 33.3 26 406 >> > Processing: 5 35 21.4 32 386 >> > Waiting: 5 30 20.4 27 383 >> > Total: 20 65 40.3 59 462 >> > Percentage of the requests served within a certain time (ms) >> > 50% 59 >> > 66% 64 >> > 75% 69 >> > 80% 72 >> > 90% 81 >> > 95% 91 >> > 98% 154 >> > 99% 269 >> > 100% 462 (longest request) >> > >> > >> > With horde: >> > >> > -- >> > nagarkot:~ ppradhan$ ab -t 10 -c 30 https://domain/h/imp/login.php >> > This is ApacheBench, Version 2.3 <$Revision: 655654 $> >> > Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ >> > Licensed to The Apache Software Foundation, http://www.apache.org/ >> > Benchmarking hostname (be patient) >> > Finished 28 requests >> > >> > Server Software: Apache/2.2.3 >> > Server Hostname: hostname >> > Server Port: 443 >> > SSL/TLS Protocol: TLSv1/SSLv3,AES256-SHA,1024,256 >> > Document Path: /h/imp/login.php >> > Document Length: 16808 bytes >> > Concurrency Level: 30 >> > Time taken for tests: 10.057 seconds >> > Complete requests: 28 >> > Failed requests: 0 >> > Write errors: 0 >> > Total transferred: 490644 bytes >> > HTML transferred: 470624 bytes >> > Requests per second: 2.78 [#/sec] (mean) >> > Time per request: 10775.575 [ms] (mean) >> > Time per request: 359.186 [ms] (mean, across all concurrent >> > requests) >> > Transfer rate: 47.64 [Kbytes/sec] received >> > Connection Times (ms) >> > min mean[+/-sd] median max >> > Connect: 9 213 220.9 269 867 >> > Processing: 660 3935 2707.5 3242 9787 >> > Waiting: 659 3934 2707.5 3241 9785 >> > Total: 926 4148 2762.9 3314 10056 >> > Percentage of the requests served within a certain time (ms) >> > 50% 3314 >> > 66% 4803 >> > 75% 6077 >> > 80% 6369 >> > 90% 8963 >> > 95% 9699 >> > 98% 10056 >> > 99% 10056 >> > 100% 10056 (longest request) >> > >> > >> > Thanks! >> > Paras. >> > On Mon, Sep 13, 2010 at 1:33 PM, John List <johnlist@xxxxxxxxxxxxxx> >> > wrote: >> >> >> >> On 09/13/2010 12:41 PM, Paras pradhan wrote: >> >> >> >> John, >> >> I am testing to support 300 requests / second. concurrent parameter in >> >> ab >> >> does test number of Established tcp session per second if I am not >> >> mistaken. >> >> Thanks >> >> Paras. >> >> >> >> Sorry again, Paras. This time I erred in two ways: I said you were >> >> testing >> >> at 300 connections per second. Actually, your -c parameter is 100 so >> >> you are >> >> testing at 100 concurrent requests (not requests per second; the actual >> >> number of requests per second is probably far higher). >> >> >> >> Suggestions: >> >> >> >> Post your complete ab results back here >> >> You might want to run your test against a (non-encrypted) http url (as >> >> well as the encrypted https url you are using) to see to see if the >> >> encryption process is a significant part of the processing time. (I'm >> >> guessing it will be.) >> >> >> >> FWIW, I'm posting my own ab results below. I ran ab from my desktop >> >> against a simple login screen on a webserver running on a dual-core >> >> laptop >> >> on the same local network using a command of "ab -t 10 -c 30 >> >> http://192.168.1.3/Login.html";. As you can see, I was actually >> >> completing >> >> 573 requests per second!: >> >> >> >> # ab -t 10 -c 30 http://192.168.1.3/Login.html >> >> This is ApacheBench, Version 2.3 <$Revision: 655654 $> >> >> Copyright 1996 Adam Twiss, Zeus Technology Ltd, >> >> http://www.zeustech.net/ >> >> Licensed to The Apache Software Foundation, http://www.apache.org/ >> >> >> >> Benchmarking 192.168.1.3 (be patient) >> >> Completed 5000 requests >> >> Finished 5734 requests >> >> >> >> >> >> Server Software: Apache/2.2.12 >> >> Server Hostname: 192.168.1.3 >> >> Server Port: 80 >> >> >> >> Document Path: /Login.html >> >> Document Length: 2409 bytes >> >> >> >> Concurrency Level: 30 >> >> Time taken for tests: 10.002 seconds >> >> Complete requests: 5734 >> >> Failed requests: 0 >> >> Write errors: 0 >> >> Total transferred: 16439378 bytes >> >> HTML transferred: 13813206 bytes >> >> Requests per second: 573.30 [#/sec] (mean) >> >> Time per request: 52.328 [ms] (mean) >> >> Time per request: 1.744 [ms] (mean, across all concurrent >> >> requests) >> >> Transfer rate: 1605.14 [Kbytes/sec] received >> >> >> >> Connection Times (ms) >> >> min mean[+/-sd] median max >> >> Connect: 0 0 0.4 0 7 >> >> Processing: 4 50 68.6 41 1918 >> >> Waiting: 3 49 68.4 41 1918 >> >> Total: 4 50 68.6 42 1919 >> >> >> >> Percentage of the requests served within a certain time (ms) >> >> 50% 42 >> >> 66% 46 >> >> 75% 50 >> >> 80% 53 >> >> 90% 81 >> >> 95% 120 >> >> 98% 180 >> >> 99% 282 >> >> 100% 1919 (longest request) >> >> # >> >> >> >> I hope this helps. (And thanks for introducing me to ab!) >> >> >> >> John >> >> >> >> On Fri, Sep 10, 2010 at 5:34 PM, John List <johnlist@xxxxxxxxxxxxxx> >> >> wrote: >> >>> >> >>> On 09/10/2010 06:09 PM, Paras pradhan wrote: >> >>> >> >>> On Fri, Sep 10, 2010 at 4:58 PM, John List <johnlist@xxxxxxxxxxxxxx> >> >>> wrote: >> >>>> >> >>>> Which processes are using the processors the most? (I suspect your >> >>>> imap >> >>>> server might be more responsible than apache.) >> >>>> >> >>>> John Hicks >> >>> >> >>> True . But I am only hitting the login.php page from ab to benchmark. >> >>> Thanks >> >>> Paras. >> >>> >> >>> (Pardon me for not reading your op more carefully.) >> >>> >> >>> I am not familiar with ab, but after a quick read, I have one >> >>> observation: >> >>> >> >>> You say you are building a system to support 200+ concurrent users on >> >>> horde. I assume that means 200 users concurrently running horde and >> >>> therefore checking their inbox every minute or so. That would be about >> >>> 3.3 >> >>> requests per second. >> >>> >> >>> It looks to me like your ab test is testing at 300.0 connections per >> >>> second. >> >>> >> >>> In other words, perhaps you needn't be too concerned about sluggish >> >>> performance from the ab test. >> >>> >> >>> John Hicks >> >>> >> >>> >> >>>> >> >>>> >> >>>> On 09/08/2010 03:42 PM, Paras pradhan wrote: >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> Looking for recommendations. >> >>>>> I need to serve 100-200+ concurrent users to provide php based >> >>>>> webmail >> >>>>> client (horde). I have setup memcached and php-fastcgid for this >> >>>>> purpose. >> >>>>> The server has four 2.2G AMD optereon cores with 8GB of memory. I am >> >>>>> doing >> >>>>> stress test using ab as: ab -t 36000 -c 100 >> >>>>> https://url/h/imp/login.php. >> >>>>> What I have noticed if the number of concurrent users are more than >> >>>>> around >> >>>>> 25, I get the sluggish performance and I can see linux load rising >> >>>>> high to >> >>>>> 25 to 30 and all the cpu cores are approximately 75% used. >> >>>>> >> >>>>> This is what I have in config files: >> >>>>> >> >>>>> mpm worker: >> >>>>> -- >> >>>>> <IfModule worker.c> >> >>>>> StartServers 15 >> >>>>> MaxClients 960 >> >>>>> MinSpareThreads 75 >> >>>>> MaxSpareThreads 150 >> >>>>> ThreadsPerChild 64 >> >>>>> MaxRequestsPerChild 5000 >> >>>>> -- >> >>>>> >> >>>>> memcached: 4GB >> >>>>> >> >>>>> --- >> >>>>> >> >>>>> fcgid: >> >>>>> >> >>>>> <IfModule !mod_fastcgi.c> >> >>>>> AddHandler fcgid-script .fcgi >> >>>>> MaxRequestsPerProcess 10000 >> >>>>> MaxProcessCount 100 >> >>>>> IPCCommTimeout 240 >> >>>>> IdleTimeout 240 >> >>>>> ProcessLifeTime 300 >> >>>>> BusyTimeout 300 >> >>>>> DefaultMaxClassProcessCount 100 >> >>>>> DefaultMinClassProcessCount 50 >> >>>>> >> >>>>> </IfModule> >> >>>>> --- >> >>>>> >> >>>>> php-fcgid: >> >>>>> >> >>>>> # Number of PHP childs that will be launched. Leave undefined to let >> >>>>> PHP decide. >> >>>>> # DefaultInitEnv PHP_FCGI_CHILDREN 4 >> >>>>> # Maximum requests before a process is stopped and a new one is >> >>>>> launched >> >>>>> DefaultInitEnv PHP_FCGI_MAX_REQUESTS 10000 >> >>>>> ---- >> >>>>> OS: RHEL 5.5 >> >>>>> Apache: 2.2.3 >> >>>>> PHP: 5.1 >> >>>>> Mysql: 5.0 >> >>>>> >> >>>>> >> >>>>> Will appreciate for any inputs. >> >>>>> >> >>>>> Thanks! >> >>>>> Paras. >> >>>>> >> >>>> >> >>>> >> >>>> --------------------------------------------------------------------- >> >>>> 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
|