General performance tuning

Discussion in 'Install/Configuration' started by ffeingol, Aug 6, 2007.

  1. ffeingol

    ffeingol Member

    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
  2. medialayer

    medialayer New Member

    Have you enabled phpsuexec?

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

    ffeingol Member

    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.
  4. mistwang

    mistwang LiteSpeed Staff

    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.
  5. ffeingol

    ffeingol Member

    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
  6. mistwang

    mistwang LiteSpeed Staff

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

    medialayer New Member

    Frank,

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

    ffeingol Member

    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
  9. medialayer

    medialayer New Member

    How did it go? :)
  10. ffeingol

    ffeingol Member

    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
  11. medialayer

    medialayer New Member

    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.
  12. ffeingol

    ffeingol Member

    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
  13. aww

    aww New Member

    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: Aug 17, 2007
  14. ffeingol

    ffeingol Member

    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
  15. aww

    aww New Member

    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)

  16. ffeingol

    ffeingol Member

    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
  17. hpham

    hpham New Member

    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,
  18. mistwang

    mistwang LiteSpeed Staff

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

    hpham New Member

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

    mistwang LiteSpeed Staff

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

Share This Page