The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

stay far from suphp !!

Discussion in 'General Discussion' started by manuk, Dec 10, 2007.

  1. manuk

    manuk Active Member

    Joined:
    Jul 6, 2005
    Messages:
    27
    Likes Received:
    0
    Trophy Points:
    6
    I moved from apache 1.3 and php 5.2.5 with eaccelerator to
    apache 2.2 with php 5.2.5 and suphp

    With apache 1.3 php 5.2.5 and eaccelerator my system load was rarely higher than 1.
    With apache 2.2/suphp my server load medium value was 6 (yes 6) and all the days the server was crashing ..

    I returned to apache dso with eaccelerator without suphp .. All works excellent now such as before ..
    Especially disabling suphp the %system usage reported by "sar" passed from a medium of 30% to only 7% !!

    If you have an old slow server stay FAR from suphp , it will mutiple your server load !!.


    The solution to solve all the problems with php , python , perl ... is chorooting users .
    Unluckly whm looks always at the easy way (phpsuxec , suphp...) but these solutions
    are not good and causes only problems to us . I truly hope WHM will decide a day (version 12?)
    to chroot users , so will not have more worries about php safe mode , suphp , openbase dir , suexec ..... and countless problems with python
    ,ruby on rails , perl , php ...
     
    #1 manuk, Dec 10, 2007
    Last edited: Dec 13, 2007
  2. dwykofka

    dwykofka Well-Known Member

    Joined:
    Aug 6, 2003
    Messages:
    394
    Likes Received:
    3
    Trophy Points:
    18
    I am not having any issues with suphp across multiple servers.

    Sometimes people have problems that are are the product of a conflict on their servers and assume that the software is simply broken and everyone should stay far away from it..

    Dont assume :)
     
  3. manuk

    manuk Active Member

    Joined:
    Jul 6, 2005
    Messages:
    27
    Likes Received:
    0
    Trophy Points:
    6
    Do you have an old pentium 4 with 1 GB of ram ? If yes , try to use suphp and see what happens.
    On fast server the problem is not visible , on al old server yes.
     
  4. dwykofka

    dwykofka Well-Known Member

    Joined:
    Aug 6, 2003
    Messages:
    394
    Likes Received:
    3
    Trophy Points:
    18
    I think the issue would be more prevelant on a server with 300 users than simply a slower server.

    I dont have any p4's but I have dual xeons with several hundred users each that are running just about the same load after suphp as they were before suphp.

    Increasing the server load is increasing the server load no matter how you look at it.

    Raptor:
    Pre suphp = .98
    Post suphp = 1.2

    That server is loaded to the gills.
     
  5. manuk

    manuk Active Member

    Joined:
    Jul 6, 2005
    Messages:
    27
    Likes Received:
    0
    Trophy Points:
    6
    well on a server with pentium 4 and 150 account you will see the difference , and it's a big diffrence .
     
  6. jayh

    jayh Active Member

    Joined:
    Apr 27, 2003
    Messages:
    29
    Likes Received:
    0
    Trophy Points:
    1
    It may be the combo of EAccelerator and suphp. I was about to try it before I saw this.

    I have no issues with suphp in 64bit on a quad processor with over 1000 - 5000 users at any given time.

    If I try to use EAccelerator with suphp, I'll let you know my results.
     
  7. VeZoZ

    VeZoZ Well-Known Member

    Joined:
    Dec 14, 2002
    Messages:
    248
    Likes Received:
    0
    Trophy Points:
    16
    cPanel Access Level:
    DataCenter Provider
    Well load average is the processes waiting in queue. So the fact with suPHP it's spawning PHP processes due to the PHP being a CGI may have something to do with such an increased load average. We have a machine that's been switched that has a higher load average but pages load just as fast. Also memory usage is 1/2 of what it was when PHP was a dso.
     
  8. manuk

    manuk Active Member

    Joined:
    Jul 6, 2005
    Messages:
    27
    Likes Received:
    0
    Trophy Points:
    6
    >
    So the fact with suPHP it's spawning PHP processes due to the PHP being a CGI may have something to do with such an increased load average
    >

    exactly . This is well visible on older server. Of course if you have quad core processors you can't notice the difference (you may notice it using a good benchmark).

    >
    If I try to use EAccelerator with suphp, I'll let you know my results.
    >

    EAccelerator with suphp will not work ! Any php accelerator on the planet does not work with suphp . If someone will not create in the future some accelerator which works with suphp no accelerator currently can work with suphp. I think that suhosin well configured (whm does not configure it!) can give the same (and perhpas better) security than suphp . With suhosin I am using eaccelerator/zend 3.3.0 and it works very very well . Also eaccelerator should be configured/tweaked a little on php.ini . I am using it with 128 MB ram and it works really good , server load rarely over 1.
     
    #8 manuk, Dec 12, 2007
    Last edited: Dec 12, 2007
  9. darren.nolan

    darren.nolan Well-Known Member

    Joined:
    Oct 4, 2007
    Messages:
    259
    Likes Received:
    0
    Trophy Points:
    16
    I like suphp. Very much so. Our average load is never over 1 either. It just depends greatly, I believe, on your server specs. As mentioned above, older servers are going to suffer with many spawns of PHP all over the place, which is fair enough.

    You should change the thread's title to "EAccelerator doesn't work with suphp" - Like dwykofka said, many people use it (and successfully without overheads described).
     
  10. manuk

    manuk Active Member

    Joined:
    Jul 6, 2005
    Messages:
    27
    Likes Received:
    0
    Trophy Points:
    6
    I did not install suphp with eaccelerator someone else suggested this. On the countrary if you read my post above I explain that it's not possible to install a php accelerator with suphp (an existent php accelerator , probably in the future someone will code an accelerator for suphp too).

    suphp overheads exists compared with DSO , simply these are not visible on a powerful machine.
    On a slow machine (old hardware with big traffic) the difference between DSO and suphp is well visible . So the title should be changed in this way "stay far from suphp if you have an old server with big traffic" .
     
    #10 manuk, Dec 13, 2007
    Last edited: Dec 13, 2007
  11. owine

    owine Active Member

    Joined:
    Jan 10, 2007
    Messages:
    44
    Likes Received:
    0
    Trophy Points:
    6
    I am using Zend Optimizer, eAccelerator, Suhosin and suPHP with Apache 2 on a Pentium D and I see no performance issues.
     
  12. manuk

    manuk Active Member

    Joined:
    Jul 6, 2005
    Messages:
    27
    Likes Received:
    0
    Trophy Points:
    6
    also if you see eaccelerator loaded using php -v

    it does NOT mean that eaccelator is working !!!!

    Install the eaccelator admin interface (each php accelerator can install an admin interface), and look if it's caching files . Well you'll see from eaccellator admin that it's NOT caching files , because eaccelerator can't work with cgi.
     
    #12 manuk, Dec 13, 2007
    Last edited: Dec 13, 2007
  13. DigitalN

    DigitalN Well-Known Member

    Joined:
    Sep 23, 2004
    Messages:
    420
    Likes Received:
    1
    Trophy Points:
    18
    I've yet to see a server get really bogged down with php-cgi opposed to mod_php and I have managed and run in excess of .. well thousands of servers running both.

    I don't think the problem is cgi opposed to mod_php, I think the issue may be with the modules/extensions installed into php or modules that people are loading on that particular box.

    I don't believe for a second suphp does what this thread claims, having run it on minimal vps servers, dual xeons, quad xeons etc..
     
Loading...

Share This Page