General performance tuning

[ffeingol]

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

[medialayer]

Have you enabled phpsuexec?

What is your current setting for "PHP suEXEC Max Conn"?

[ffeingol]

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.

[mistwang]

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]

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

[mistwang]

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

[medialayer]

Frank,

I asked this in another thread, but what did you set for "Initial Request Timeout"?

[ffeingol]

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

[medialayer]

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

How did it go? :)

[ffeingol]

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

[medialayer]

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

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 (http://xcache.lighttpd.net/), 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]

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

[aww]

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.

[ffeingol]

This is how we have eAccelerator setup:


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

[aww]

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)

This is how we have eAccelerator setup:


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

[ffeingol]

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

[hpham]

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,

[mistwang]

20 should be enough, you can monitor the realtime statistic report, to make sure the "WaitQ" is at zero for the most of time.

[hpham]

If this number is set too high, for example, 50, is this affecting to the performance?

[mistwang]

Set it too high may not help with performance, but make it worse. It could make your server weaker when fighting a DoS attack.

[anewday]

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.

Isn't that too low for a forum since it has many php pages and restricting it to 1 a second will slow down the loading times.

[layer]

Isn't that too low for a forum since it has many php pages and restricting it to 1 a second will slow down the loading times.

If I'm not mistaken, this is on a per client (i.e. visitor) basis (for DDOS Protection), not per site basis.

[anewday]

Yes, that's what I meant. It'll slow down loading the forums for a visitor, wouldn't it?

[layer]

Yes, that's what I meant. It'll slow down loading the forums for a visitor, wouldn't it?

Not under normal conditions. Typically a visitor won't be browsing so quickly that they would hit that limit.

[anewday]

But it doesn't take much to exceed 1 dynamic request a second.

[layer]

But it doesn't take much to exceed 1 dynamic request a second.

Give it a try and find out what works out best for you...