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
|