Best configuration for PHP LiteSpeed SAPI

[jeff]

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

[mistwang]

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

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

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:

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

[bkonia]

Originally Posted by mistwang

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.

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

[mistwang]

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.

[SyNeo]

Hi.

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

[SyNeo]

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?

[mistwang]

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.