Sorry Paras, I didn't catch it right , then the behavior is : Database based (Performs Wrong) Non Database based (perform good) html files (performs good) is this right ? Asuming this is the case, then you should check your database server to see if you're seeing stress signs on it. Also, if you really want to load-test your application, then you should consider a more complex test, using jmeter or some other testing tool, where you can create random waits and other test artifacts. Regards, Pablo On Tue, Sep 14, 2010 at 5:22 PM, Paras pradhan <pradhanparas@xxxxxxxxx> wrote: > Just confirmed that the runtime wait is happening to all the database based > and non database based php scripts and with plain html files it is fine. > Ideas? > Paras. > > On Tue, Sep 14, 2010 at 12:46 PM, Paras pradhan <pradhanparas@xxxxxxxxx> > wrote: >> >> Yes horde is based on PHP and Mysql. But the page I am hitting with ab is >> just the login page and no database involved. >> Paras. >> >> On Tue, Sep 14, 2010 at 12:43 PM, Pablo Garcia Melga <malevo@xxxxxxxxx> >> wrote: >>> >>> 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 >>> >> > > --------------------------------------------------------------------- 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
|