Horible performance

Discussion in 'PHP' started by ffeingol, Aug 7, 2007.

  1. ffeingol

    ffeingol Well-Known Member

    Some background,

    We're running LSWS 3.2.1 On a Dual Xeon 3.0 ghz, 2 gb of memory. It's a cPanel box and it was running Apache. PHP is a fresh build of 4.4.7 with eAccelerator.

    The PHP LSAPI is set:

    Max Connections: 30
    Initial Request Timeout: 60
    Process Soft Limt: 220
    Process Hard Limit: 220

    We also have Throttling set to 20 / sec for static and 1 / sec for dynamic

    On the real-time reort for External Applications we see:

    Max Conn: 60
    Eff Max: 60

    And a lot of time there are processes in the wait queue. This is not a particularly busy server. I'm watching the VHOST Requests: _Server graph and it's maxing at 30 requests per second.

    Any clues, thoughs, suggestions on why PHP is running so slowly? We have a couple of clients that actively monitor their sites and it's noticeably slower since we put in LSWS. I want to give it a chance, but at this rate, we're going to have to back it out and go back to Apache.


  2. mistwang

    mistwang LiteSpeed Staff

    First, you need to verify that eAccelerator works properly.
    Then, you can increase the "Max Connections" and "PHP_LSAPI_CHILDREN" to 40, to keep the Wait Q at zero for the most of the time.

    We recommend PHP suEXEC, it assigns dedicate PHP processes for each account, so you can easily identify a site which is causing problem. This way, one site was hitting hard will not affect other sites.

    The slow down might because one site got higher than normal traffic like you said in other thread. You can switch back and forth and compare between Apache and LSWS, and we are interested to know the result as well.
  3. ffeingol

    ffeingol Well-Known Member

    Done. I'd also love to get the cacti plugin working but we don't have php V5 on our cacti box, so I can't. That (I think) would help at least know what we're dealing with.

    Unfortunately this is not something that can be easily done (unless I'm totally missing things). We have dozens of site (for example) that run gallery. All the uploaded images are owned by "nobody" as well as various .dat files. We'd have to chown all those to the site owner id and keep a list of all of them if we needed to backup to Apache. That is a huge task.

    Yes, it may be but the anti-dos features of LSWS is what we were hoping would "smooth" all this out. Believe me, I totally want this solution to work as it opens so many possibilities.


  4. ffeingol

    ffeingol Well-Known Member

    Sorry, I forgot to mention, eAccelerator is working fine. From the eAcceletaor control page:

    Caching enabled:  yes
    Optimizer enabled:  yes
    Memory usage:  99.99% (32.00MB/ 32.00MB)
    Free memory:  0.00MB
    Cached scripts:  410
    Removed scripts:  0
    Cached keys:  0
  5. mistwang

    mistwang LiteSpeed Staff

    If the uploaded images are world readable, then you don't have to change the ownership.

    Anti-DoS feature will help defending attacks, traffic from valid users still need to to be served as usual. So, you will definitely see different load when serving 1000 users than serving 500 users. Switching between Apache and LiteSpeed while the server receiving same amount of traffic and compare.
  6. medialayer

    medialayer Active Member

    Try using Apache Benchmark with and without LSWS and see how many "requests per second" you are able to obtain. On a standard cPanel install, ab is located in /usr/local/apache/bin/ab. Please share the results too :)
  7. ffeingol

    ffeingol Well-Known Member

    I can certainly do that. It seems to mostly be a php/mysql issue and our backups may be playing a wee part of the issue also.

    Any suggestions for ab parms? I'd like a good test, but I don't want to totally knock the server over either (it's a prod box).


  8. medialayer

    medialayer Active Member

    Try tuning-primer to help optimize your MySQL configuration if you haven't already.

    You can start with very basic parameters, I usually do something like "ab -c 5 -n 10" for a small test and expand from there. I don't think you'll have a problem with "ab -c 20 -n 100". Do a few tests and get an average.

    edit: Also, what are you doing as far as gzip compression? If you are doing dynamic compression I would try disabling it, since many PHP applications (i.e. vBulletin) already have this built in. A better way would of course be to disable the compression in those applications themselves, but I guess you can't really force your customers to change that. If you are using the default of 6, I tend to use 1 which seems most beneficial to me (I'm more CPU-conscious than I am about 2-3% increase in file size).
    Last edited: Aug 10, 2007
  9. ffeingol

    ffeingol Well-Known Member

    Its more bad client code/sql calls that mysql tuning. It's hard to get clients to change their code, but they are usually happy if we get them better sql that speeds up their sites.

    If I understand this coorect -c 20 -n 100 is 20 clients doing 100 calls (so 5 calls each)? I don't think that either Apache or LSWS would even blink at that.

    We can't turn off gzip (don't want the bandwidth bill going through the roof) but we plan on adjusting the compression level back to 1. We have also found that the cpu utilization goes way up past 1 but the additional compression is nominal.

  10. medialayer

    medialayer Active Member

    Nope, they won't, but it should be a start for measuring performance. Just keep increasing as you feel comfortable. It depends on the script you are benchmarking as well.
  11. mistwang

    mistwang LiteSpeed Staff

    If PHP send back compressed content, LiteSpeed will send it as is without trying to compress it again. So, it does not hurt to leave it on.
    Yes, use compression level 1 if you want to save some CPU cycles.
  12. medialayer

    medialayer Active Member

    Ah, I was wondering if it functioned in that way. Good to hear that.
  13. mistwang

    mistwang LiteSpeed Staff

    When you do a "ab" benchmark, you may need to turn off LSWS request rate throttling in order to get meaningful results.
  14. medialayer

    medialayer Active Member


    I wanted to share my test results:

    I did ab -c 5 -n 100 against a phpinfo() on both Apache & LSWS. Same server, same php.ini, same PHP version, same PHP configure command (besides --with-litespeed, etc.):

    Apache mod_php5 average:
    Requests per second: 714.29 [#/sec]

    LSWS average:
    Requests per second: 1449.28 [#/sec]

    Both have eAccelerator.
  15. ffeingol

    ffeingol Well-Known Member

    Our results bounce around way too much to be meaningful with those parms:


    Requests per second: 316.58 [#/sec] (mean)
    Requests per second: 251.63 [#/sec] (mean)
    Requests per second: 215.95 [#/sec] (mean)


    Requests per second: 674.75 [#/sec] (mean)
    Requests per second: 127.43 [#/sec] (mean)
    Requests per second: 239.89 [#/sec] (mean)

    Exact same php/php.ini yadda, yadda, yadda.


Share This Page