httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pablo Garcia Melga <mal...@gmail.com>
Subject Re: [users@httpd] High load apache
Date Tue, 14 Sep 2010 22:00:46 GMT
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@gmail.com> 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@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
>>>
>>
>
>

---------------------------------------------------------------------
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