Best configuration for PHP LiteSpeed SAPI

Discussion in 'Install/Configuration' started by jeff, Sep 27, 2005.

  1. jeff

    jeff New Member

    Hello All!

    I have installed LiteSpeed Web Server 2.1.1 Standard Edition on linux (Trustix 3 / kernel 2.6).
    For test I have compiled PHP 5.0.4 in FastCGI and LiteSpeed PHP SAPI mode.
    In my all benchmarks tests with ApacheBench the php in FastCGI mode is more fast than PHP SAPI :

    ab -c 298 -n 10000 "http://myserver/phpinfo.php" (LiteSpeed PHP SAPI):
    Concurrency Level: 298
    Time taken for tests: 33.717688 seconds
    Complete requests: 10000
    Failed requests: 9962
    (Connect: 0, Length: 9962, Exceptions: 0)
    Write errors: 0
    Total transferred: 373412827 bytes
    HTML transferred: 371991430 bytes
    Requests per second: 296.58 [#/sec] (mean)
    Time per request: 1004.787 [ms] (mean)
    Time per request: 3.372 [ms] (mean, across all concurrent requests)
    Transfer rate: 10815.09 [Kbytes/sec] received

    ab -c 298 -n 10000 "http://myserver/phpinfo.php" (LiteSpeed PHP FCGI):
    Concurrency Level: 298
    Time taken for tests: 19.784013 seconds
    Complete requests: 10000
    Failed requests: 28
    (Connect: 0, Length: 28, Exceptions: 0)
    Write errors: 0
    Total transferred: 403320418 bytes
    HTML transferred: 401916036 bytes
    Requests per second: 505.46 [#/sec] (mean)
    Time per request: 589.564 [ms] (mean)
    Time per request: 1.978 [ms] (mean, across all concurrent requests)
    Transfer rate: 19908.35 [Kbytes/sec] received

    I have tried many options in theLiteSpeed server configuration for LiteSpeed PHP SAPI, but LiteSpeed PHP FCGI always win.

    What the best LiteSpeed Standard Edition PHP SAPI server configuration for the following parameters?
    Max Connections?
    Environment?
    Response Bufferring?
    Auto Start?
    Instances?
    Priority?

    Thanks,

    Jefferson
  2. mistwang

    mistwang LiteSpeed Staff

    Hi Jefferson,

    We did some performance test today.

    Our test result shows that the scalability of poll is very bad when concurrent level is high, and LiteSpeed PHP has worse performance than FCGI PHP, when epoll is used, LiteSpeed PHP always win.
    The poll() implementation in 2.6 Kernel is worse than that in 2.4, we think.

    Our result:
    FCGI PHP
    Code:
    ab -n 10000 -c 298 http://192.168.10.45:8088/phpinfo.php
    
    Concurrency Level:      298
    Time taken for tests:   21.250 seconds
    Complete requests:      10000
    Failed requests:        0
    Broken pipe errors:     0
    Total transferred:      255775919 bytes
    HTML transferred:       254333788 bytes
    Requests per second:    470.59 [#/sec] (mean)
    Time per request:       633.25 [ms] (mean)
    Time per request:       2.12 [ms] (mean, across all concurrent requests)
    Transfer rate:          12036.51 [Kbytes/sec] received
    
    LiteSpeed PHP
    Code:
    ab -n 10000 -c 298 http://192.168.10.45:8088/phpinfo.phtml
    
    Concurrency Level:      298
    Time taken for tests:   19.020 seconds
    Complete requests:      10000
    Failed requests:        0
    Broken pipe errors:     0
    Total transferred:      240157735 bytes
    HTML transferred:       238716105 bytes
    Requests per second:    525.76 [#/sec] (mean)
    Time per request:       566.80 [ms] (mean)
    Time per request:       1.90 [ms] (mean, across all concurrent requests)
    Transfer rate:          12626.59 [Kbytes/sec] received
    
    Our LiteSpeed PHP configuration:
    Code:
    Name	   lsphp
    Address	uds://tmp/lshttpd/lsphp.sock
    Max Connections	20
    Environment	PHP_LSAPI_CHILDREN=20
    PHP_LSAPI_MAX_REQUESTS=500
    
    Initial Request Timeout (secs)	60
    Retry Timeout (secs)	0
    Response Bufferring	No
    Auto Start	Yes
    Command	$VH_ROOT/fcgi-bin/lsphp
    Back Log	100
    Instances	1
    
    And we found that PHP 4.4.0 is about 50% faster than PHP 5.0.4 for both FCGI PHP and LiteSpeed PHP.

    Best Regards,
    George Wang
  3. bkonia

    bkonia New Member

    George,

    My understanding of your test results is that if you're running a 2.4 kernel and therefore using poll, you will get better performance with FCGI PHP. And, if you are running a 2.6 kernel and using epoll, you will get better performance with LSAPI PHP.

    Is that an accurate assessment?

    --
    Brad S Konia
  4. mistwang

    mistwang LiteSpeed Staff

    LSAPI PHP is faster than FCGI PHP on a 2.4 kernel with poll as well.
    We believe that the poll implementation in 2.4 kernel is better than that in 2.6 kernel. When poll is used on a 2.6 kernel, LSAPI PHP is slower than FCGI PHP when client concurrent level is high, at least for our standard edition.
    When epoll is used, LSAPI PHP always win.
  5. SyNeo

    SyNeo New Member

    Hi.

    So, basically switching poll to epoll in the tuning page, will be enough to improve the performance with LSAPI?
  6. SyNeo

    SyNeo New Member

    Hi.

    Are there any possible caveats in using epoll instead of poll? I switched and it looks fine currently, but perhaps there some points I should be aware of?
  7. mistwang

    mistwang LiteSpeed Staff

    There is no known issue with epoll, should be safe to use it in production.
    Epoll has advantage over poll only when concurrent level is high, otherwise, you will not see big differences.

Share This Page