General performance tuning

ffeingol

ffeingol

Well-Known Member
#1
#1
Hello All,

We have a trial of LSWS Enterprise running on a not too busy shared hosting box. There are about 200 domains on the server. For the most part the sites on the server are PHP/MySQL driven. Things went pretty well today but we did have a couple of load spikes and at one point all the php processes were used up. So a couple of general performance questions:

- What would be a "reasonable" number for PHP_LSAPI_CHILDREN
- Are there any other PHP_LSAPI variables we should be looking at / tuning for PHP?

DoS Questions

- What is a reasonable value for static requests / second?
- What is a reasonable value for dynamic requests / second?
- Are the any other DoS variables we should be looking at?

I know of lot of this will "depend on our situation" but a reasonable starting point will help.

TIA,

Frank
 
ffeingol

ffeingol

Well-Known Member
#3
#3
For right now we are not running suexec. Under Apache the load was just too much running php as a cgi. It's something we're definitely going to look into but it's a big undertaking to switch.
 
M

mistwang

LiteSpeed Staff
#4
#4
If you do not use suEXEC, 20-40 should be a good value for PHP_LSAPI_CHILDREN and "Max Conns".
If you use suEXEC, set "PHP suEXEC Max Conn" between 5-10 is a good start point.

We usually set static RPS to 20, and set dynamic RPS to 1. you can also set connection limits and bandwidth throttling for anti-DDoS purpose.
 
ffeingol

ffeingol

Well-Known Member
#5
#5
Anything else we should be looking at? The I/O Event Dispatcher looked "interesting" but we're just on the default "best". We're running CentOS 4 with a 2.6 kernel.

Performance is not bad per-se, but the load is actually a bit higher than when we ran Apache. For now I think it's because we've disabled eaccelerator (we did a php upgrade at the same time as switching). We'll be installing APC later this evening after things quite down a bit.

TIA,

Frank
 
M

mistwang

LiteSpeed Staff
#6
#6
"Best" is the best available, should use "epoll" under the hood.

If most sites are PHP driven, the opcode cache is a huge factor, and you can try both APC and eAccelerator and see which work best for you. If you were using eAccelerator with Apache, use eAccelerator for the load comparison. We are very interested in the results as well.
 
ffeingol

ffeingol

Well-Known Member
#8
#8
medialayer,

We had left it at the default (60 I believe) but we'll be adjusting it later tonight. Trying to not tweak too many things at once ;)

mistwang,

We have recompiled and re-enabled eaccelerator.

Frank
 
ffeingol

ffeingol

Well-Known Member
#10
#10
It's still "fair to partly cloudy" :D We were able to get eaccelerator back in but loads are still bouncing all over the place. We simply have not had time to play with any of the other suggested configs yet. That will be tomorrows task.

To make it more fun, one of the Blogs we host got semi-slashdotted today so that just added to the misery.

Anyone have any feedback on eaccelerator vs APC?

TIA,

Frank
 
M

medialayer

Active Member
#11
#11
ffeingol said:
It's still "fair to partly cloudy" :D We were able to get eaccelerator back in but loads are still bouncing all over the place. We simply have not had time to play with any of the other suggested configs yet. That will be tomorrows task.

To make it more fun, one of the Blogs we host got semi-slashdotted today so that just added to the misery.

Anyone have any feedback on eaccelerator vs APC?

TIA,

Frank
Click to expand...
I have done some benchmarks on APC vs. eAccelerator and have found APC to be slightly better in certain cases, but, if you need Zend Optimizer then APC will not work. eAccelerator, on the other hand, works perfectly fine alongside Zend Optimizer. Also, you can even load IonCube if you wish, if you load eAccelerator as just an 'extension' as opposed to a 'zend_extension'.

Another interesting project is XCache, however I personally prefer eAccelerator out of the whole bunch.

YMMV.

P.S. I have experienced some eAccelerator crashes when used with PHP 5, however this is not 'too' much to worry about. If need be, eAccelerator can be disabled via .htaccess.
 
ffeingol

ffeingol

Well-Known Member
#12
#12
Well we have to have Zend (for encoded programs) so eAccelerator it is. We'll be putting the other changes in a bit later this morning and hopefully it levels things out just a bit.

TIA,

Frank
 
A

aww

Well-Known Member
#13
#13
Eaccelerator just simply has more stability and fewer faults than APC from everything I've read. It's slightly slower in raw benchmarks but apparently not in real world testing.

Running with eaccelerator is a must for any serious host.
Radically reduces memory use and server load for any website that's reliant on PHP.
 
Last edited:
ffeingol

ffeingol

Well-Known Member
#14
#14
This is how we have eAccelerator setup:

Code: 
zend_extension="/xxx/php4/lib/php/extensions/no-debug-non-zts-20020429/eaccelerator.so"
eaccelerator.shm_size="32"
eaccelerator.cache_dir="/xxx/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="0"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="3600"
eaccelerator.shm_prune_period="180"
eaccelerator.shm_only="0"
eaccelerator.compress="0"
eaccelerator.compress_level="9"
eaccelerator.allowed_admin_path="/xxx/xxx/xxx/"
It seems to help quite a bit, but we're only able to get 400 or so scripts cached (from the control.php page). On a busy shared server that is just a drop in the bucket.

Frank
 
A

aww

Well-Known Member
#15
#15
On a busy host, perhaps 32 megs is not enough and your ttl is only an hour? That may explain the 400 limit. (all this is just theory as I have no experience over five virtual hosts at this point)

ffeingol said:
This is how we have eAccelerator setup:

Code: 
zend_extension="/xxx/php4/lib/php/extensions/no-debug-non-zts-20020429/eaccelerator.so"
eaccelerator.shm_size="32"
eaccelerator.cache_dir="/xxx/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="0"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="3600"
eaccelerator.shm_prune_period="180"
eaccelerator.shm_only="0"
eaccelerator.compress="0"
eaccelerator.compress_level="9"
eaccelerator.allowed_admin_path="/xxx/xxx/xxx/"
It seems to help quite a bit, but we're only able to get 400 or so scripts cached (from the control.php page). On a busy shared server that is just a drop in the bucket.

Frank
Click to expand...
 
ffeingol

ffeingol

Well-Known Member
#16
#16
Unless you play with the kernel settings (from what I understand) 32 meg is the largest shared memory segment that you can grab. I also believe that the TTL is only used to determine when something can get bumped out of memory (i.e. you want to cache something new and then things over an hour old can get bumped out).

Frank
 
H

hpham

Active Member
#17
#17
How about the value of PHP suEXEC Max Conn for just one site on its dedicated server? It's a vBulletin with 500 - 600 members online at any time

Thanks,
 
You must log in or register to reply here.
Top