httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paras pradhan <pradhanpa...@gmail.com>
Subject Re: [users@httpd] High load apache
Date Tue, 14 Sep 2010 20:22:55 GMT
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@gmail.com>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@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
>>
>>
>

Mime
View raw message