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@gmail.com> 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@gmail.com> 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@gmail.com>
> 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@gmail.com>
>> 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@gulfbridge.net>
>> > 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@gulfbridge.net>
>> >> wrote:
>> >>>
>> >>> On 09/10/2010 06:09 PM, Paras pradhan wrote:
>> >>>
>> >>> On Fri, Sep 10, 2010 at 4:58 PM, John List <johnlist@gulfbridge.net>
>> >>> 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@httpd.apache.org
>> >>>>  "   from the digest: users-digest-unsubscribe@httpd.apache.org
>> >>>> For additional commands, e-mail: users-help@httpd.apache.org
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> 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@httpd.apache.org
>>   "   from the digest: users-digest-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>
>

---------------------------------------------------------------------
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@httpd.apache.org
  "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org