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 <johnl...@gulfbridge.net <mailto:johnl...@gulfbridge.net>> wrote:

    On 09/10/2010 06:09 PM, Paras pradhan wrote:

    On Fri, Sep 10, 2010 at 4:58 PM, John List
    <johnl...@gulfbridge.net <mailto:johnl...@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-unsubscr...@httpd.apache.org
        <mailto:users-unsubscr...@httpd.apache.org>
         "   from the digest:
        users-digest-unsubscr...@httpd.apache.org
        <mailto:users-digest-unsubscr...@httpd.apache.org>
        For additional commands, e-mail: users-h...@httpd.apache.org
        <mailto:users-h...@httpd.apache.org>





Reply via email to