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.

uphp vs fastcgi & eaccelerator

Discussion in 'General Discussion' started by h4f, Dec 27, 2008.

  1. h4f

    h4f Well-Known Member

    Joined:
    Jun 5, 2007
    Messages:
    63
    Likes Received:
    0
    Trophy Points:
    6
    I have trying to find helpful documents online about suphp and fastcgi but there is not much out there.

    The issue a dedicated customer wants a WHM/CPanel server which all PHP sites are running under their own useraccount, low memory print and fast.

    Suphp (with suhosin) disables eaccelerator.
    Fastcgi is not recommend and has a large memory footprint (up to three time in comparison to mod_php/dso)

    I found this document: http://www.cpanel.net/conference/08/files/EA3PHPConfiguration.pdf

    SuPHP:
    Higher security replacement for PHPSuexec
    Runs PHP as the user (regardless of suexec setting)
    Very configurable
    Very secure
    Simple dual-PHP setup

    SuPHP Drawbacks:
    Slow
    Doesn't handle DSO style Apache directives
    Security checks may confuse some users

    Recommended by Cpanel

    FCGID (FastCGI):
    Designed to be the best of DSO and SuPHP
    Runs PHP as the user or nobody depending on
    suexec setting
    Fast

    FCGID (FastCGI) Drawbacks:
    Complicated to configure
    http://fastcgi.coremail.cn/
    High memory usage
    Prevents users from accessing the cPanel PHP
    selector
    Doesn't handle DSO style Apache directives
    NOT RECOMMENDED

    According to me the only good option is suphp with Eaccelerator.


    According to Eaccelerator.net.

    So it is a structural issue that isn't going to be solved.

    The question that I have is if someone has measured performance + memory footprint for this combinations:

    1) DSO + eaccelerator
    2) suphp (suhosin) (and ZEND optimizer?)
    3) FastCGI

    So that the "cost" per option can become visible.
     
    #1 h4f, Dec 27, 2008
    Last edited: Dec 27, 2008
  2. h4f

    h4f Well-Known Member

    Joined:
    Jun 5, 2007
    Messages:
    63
    Likes Received:
    0
    Trophy Points:
    6
    Code:
                               Load TestTime	failed	Request/s time/req transferrate FreeMEM	Recovery after highload (giving free CPU and memory resources)
    DSO with Eaccelerator	        26	58	134	8.59	11635	150Kb/s	1035296k	fast
    DSO without Eaccelerator	51	70	178	7.09	14113	114Kb/s	761672k	fast
    FastCGI with Eaccelerator	32	59	134	8.35	11974	149Kb/s	547820k	slow
    FastCGI without Eaccelerator	41	72	122	6.93	14473	122Kb/s	590952k	slow
    SuPHP	                        65	73	119	6.83	14643	120Kb/s	1191860k	fastest
    
    I find four things important:
    1) CPU load
    2) Memory consumption
    3) Response times
    4) Recovery time after highload (garbage collection)

    DSO is not an option as described in previous posting.

    So only SuPHP and Fcgid stay.

    SuPHP has low memory footprint and is very fast with garbage collection (in fact after page is rendered it gives the resources free) but has a high disk I/O so not suitable for software raid/sata/ide servere therefore causing highloads and also not able to use Eaccelerator.

    FCGID has lower cpu resources (near DSO), the memory consumption is almost twice (in this test, I read that it can cost up to 4 times) more then DSO or SUPHP. Response is as good as DSO only recovery time is very slow.

    Nevertheless CPU + DISK I/O cost more then memory does and as it uses Eaccelerator rendered PHP pages that are nearly static and contain allot of content will benefit even more.

    Conclusion I hope that Cpanel is going to look at FastCGI because SuPHP is not an good alternative, besides this with last cpanel it became "accelerated" "You Can Really" accelerate cpanel by supporting FastCGI instead of SuPHP.

    Test was done on dual xeon 3.8 with 6GB memory reading from RAID5 15K U320 scsi disks. SuPHP does allot of disk I/O so on a Q6600 with software RAID1 the performance is degraded much more.
    To give you an example Failed requests: 273

    The only question that I have, which thinks that I have to keep in mind when migrating servers from suPHP to fcgid.

    Below the raw data:

    In all test I waited untill server has load average < 1

    ab -n500 -c100 http://

    fastcgi + Eaccelarator enabled

    default joomla site

    top - 15:00:41 up 1 day, 12:29, 1 user, load average: 31.97, 11.82, 8.31
    Mem: 6048544k total, 5500724k used, 547820k free, 130376k buffers

    Document Length: 17240 bytes

    Concurrency Level: 100
    Time taken for tests: 59.871875 seconds
    Complete requests: 500
    Failed requests: 134
    (Connect: 0, Length: 134, Exceptions: 0)
    Write errors: 0
    Total transferred: 9141604 bytes
    HTML transferred: 8614104 bytes
    Requests per second: 8.35 [#/sec] (mean)
    Time per request: 11974.375 [ms] (mean)
    Time per request: 119.744 [ms] (mean, across all concurrent requests)
    Transfer rate: 149.10 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 3 1277 3924.7 4 21004
    Processing: 792 9574 4446.6 8563 29131
    Waiting: 780 9550 4442.2 8550 29116
    Total: 815 10852 5910.0 9179 39755

    Percentage of the requests served within a certain time (ms)
    50% 9179
    66% 11714
    75% 13623
    80% 14921
    90% 17522
    95% 22067
    98% 29983
    99% 32874
    100% 39755 (longest request)







    fastcgi + Eaccelarator DISABLED

    default joomla site (notice the free mem when disabling eaccelerator)
    top - 14:08:58 up 1 day, 11:37, 1 user, load average: 41.26, 12.73, 6.77
    Mem: 6048544k total, 5457592k used, 590952k free, 119780k buffers

    Document Length: 17240 bytes

    Concurrency Level: 100
    Time taken for tests: 72.367447 seconds
    Complete requests: 500
    Failed requests: 122
    (Connect: 0, Length: 122, Exceptions: 0)
    Write errors: 0
    Total transferred: 9092503 bytes
    HTML transferred: 8566869 bytes
    Requests per second: 6.91 [#/sec] (mean)
    Time per request: 14473.489 [ms] (mean)
    Time per request: 144.735 [ms] (mean, across all concurrent requests)
    Transfer rate: 122.69 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 3 1067 3069.0 4 21001
    Processing: 736 12244 6929.3 10748 45236
    Waiting: 724 12189 6894.0 10732 45216
    Total: 760 13311 7743.2 11252 52863

    Percentage of the requests served within a certain time (ms)
    50% 11252
    66% 13445
    75% 16157
    80% 18609
    90% 22741
    95% 28189
    98% 36421
    99% 43830
    100% 52863 (longest request)





    DSO (mod_php) without EACCELERATOR

    default joomla site
    top - 14:22:48 up 1 day, 11:51, 1 user, load average: 50.95, 15.51, 8.15
    Mem: 6048544k total, 5286872k used, 761672k free, 122580k buffers

    Document Length: 17240 bytes

    Concurrency Level: 100
    Time taken for tests: 70.569462 seconds
    Complete requests: 500
    Failed requests: 178
    (Connect: 0, Length: 178, Exceptions: 0)
    Write errors: 0
    Total transferred: 8267413 bytes
    HTML transferred: 7752863 bytes
    Requests per second: 7.09 [#/sec] (mean)
    Time per request: 14113.893 [ms] (mean)
    Time per request: 141.139 [ms] (mean, across all concurrent requests)
    Transfer rate: 114.40 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 3 773 2178.7 4 9005
    Processing: 897 11998 9235.7 9482 62550
    Waiting: 865 11948 9225.9 9451 62517
    Total: 921 12771 9919.1 10310 62554

    Percentage of the requests served within a certain time (ms)
    50% 10310
    66% 12346
    75% 14079
    80% 15591
    90% 21817
    95% 31320
    98% 49998
    99% 54551
    100% 62554 (longest request)



    DSO (mod_php) WITH EACCELERATOR



    default joomla site
    top - 14:54:46 up 1 day, 12:23, 1 user, load average: 26.25, 8.46, 7.45
    Tasks: 269 total, 27 running, 218 sleeping, 0 stopped, 24 zombie
    Cpu0 : 69.9%us, 27.8%sy, 0.0%ni, 2.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
    Cpu1 : 85.1%us, 14.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
    Cpu2 : 67.5%us, 28.8%sy, 0.0%ni, 3.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
    Cpu3 : 78.9%us, 19.5%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.3%hi, 1.3%si, 0.0%st
    Mem: 6048544k total, 5013248k used, 1035296k free, 129216k buffers
    Swap: 2048276k total, 96k used, 2048180k free, 3639152k cached


    Document Length: 17240 bytes

    Concurrency Level: 100
    Time taken for tests: 58.178534 seconds
    Complete requests: 500
    Failed requests: 134
    (Connect: 0, Length: 134, Exceptions: 0)
    Write errors: 0
    Total transferred: 8992737 bytes
    HTML transferred: 8458017 bytes
    Requests per second: 8.59 [#/sec] (mean)
    Time per request: 11635.707 [ms] (mean)
    Time per request: 116.357 [ms] (mean, across all concurrent requests)
    Transfer rate: 150.93 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 3 779 2181.1 4 9006
    Processing: 283 9131 4853.0 8472 35942
    Waiting: 262 9098 4854.0 8422 35915
    Total: 309 9911 5218.7 8680 42886

    Percentage of the requests served within a certain time (ms)
    50% 8680
    66% 10172
    75% 12121
    80% 13113
    90% 16299
    95% 19018
    98% 24391
    99% 30433
    100% 42886 (longest request)


    Suphp

    default joomla site
    top - 14:39:06 up 1 day, 12:08, 1 user, load average: 65.77, 23.46, 12.57
    Tasks: 276 total, 36 running, 234 sleeping, 0 stopped, 6 zombie
    Cpu0 : 80.5%us, 19.5%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
    Cpu1 : 83.5%us, 14.2%sy, 0.0%ni, 2.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
    Cpu2 : 76.2%us, 23.4%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
    Cpu3 : 83.9%us, 15.5%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.3%hi, 0.3%si, 0.0%st
    Mem: 6048544k total, 4856684k used, 1191860k free, 125952k buffers
    Swap: 2048276k total, 96k used, 2048180k free, 3701832k cached



    Document Length: 17240 bytes

    Concurrency Level: 100
    Time taken for tests: 73.219344 seconds
    Complete requests: 500
    Failed requests: 119
    (Connect: 0, Length: 119, Exceptions: 0)
    Write errors: 0
    Total transferred: 9063660 bytes
    HTML transferred: 8536200 bytes
    Requests per second: 6.83 [#/sec] (mean)
    Time per request: 14643.869 [ms] (mean)
    Time per request: 146.439 [ms] (mean, across all concurrent requests)
    Transfer rate: 120.88 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 3 1253 3839.6 4 21003
    Processing: 870 12284 13125.9 6830 71491
    Waiting: 858 12068 12926.3 6743 68867
    Total: 889 13537 13748.3 7362 72751

    Percentage of the requests served within a certain time (ms)
    50% 7362
    66% 9857
    75% 16652
    80% 22764
    90% 32977
    95% 45004
    98% 54431
    99% 70077
    100% 72751 (longest request)
     
    #2 h4f, Dec 27, 2008
    Last edited: Dec 27, 2008
  3. kampret

    kampret Member

    Joined:
    Jun 21, 2007
    Messages:
    20
    Likes Received:
    0
    Trophy Points:
    1
    I've facing this dilemmatic options either.

    1. DSO + Eaccelerator = Ultra perfect for speed, BUT totally not secure.

    2. FCGI + Eacceleator = Mostly spitting out "error 500" pages. Many problems will raised after switch to this option (especially with ±500 sites inside your server)

    3. suPHP = Totally secure, but totally SLOW.


    So?


    Personally I am stay with DSO + Eaccelerator.
    Server security is handled by mod_security custom rules.
    "nobody" problems? just use chown -R /home/user/public_html/*
     
  4. kampret

    kampret Member

    Joined:
    Jun 21, 2007
    Messages:
    20
    Likes Received:
    0
    Trophy Points:
    1
    Btw, on Cpanel, between SLOW and FAST is mostly depend on webserver it self.
    And unfortunatelly, Apache is the most suspect thing for being make this SLOW problems happen.

    There'll be impossible to get "SECURE but FAST" if Cpanel still using Apache as webserver.
    So you must accept your destiny and satisfied with just : "SECURE but SLOW" :)


    Then, let's pray for Cpanel to finally provide "Webserver Selection" under their Service Configuration menu on WHM :p
     
  5. dropby23

    dropby23 Well-Known Member

    Joined:
    Jan 16, 2005
    Messages:
    155
    Likes Received:
    0
    Trophy Points:
    16
    for shared environment i use suphp but for my server i seu dso + eaccelerator it is really fast but as mentioned before it is totally unsecure
     
  6. Infopro

    Infopro cPanel Sr. Product Evangelist
    Staff Member

    Joined:
    May 20, 2003
    Messages:
    14,478
    Likes Received:
    203
    Trophy Points:
    63
    Location:
    Pennsylvania
    cPanel Access Level:
    Root Administrator
    Twitter:
    Let me get this staight, you have one Joomla site on that server above, and get the loads you mention on all tests?

    I'd suggest SuPHP and going over that site from top to bottom, it's got some serious problems.
     
  7. h4f

    h4f Well-Known Member

    Joined:
    Jun 5, 2007
    Messages:
    63
    Likes Received:
    0
    Trophy Points:
    6
    Do you run chown -R nobody:nobdoy /home/user/public_html/* each minute?

    Because customer tend to use FTP and webupload (with most CMS system) at the same time.

    The most insecure feature with DSO is that when site is running nobody that customer can upload PHP script (or someone abusing his account) and will have permission to read and write alll configuration.php and/or index.html/index.php on the server, enabling mass deface.

    While FTP doesn't allow customer to look in other homedirs APACHE nobody proces doesn't protect you from that.

    How they find account on your server? Simple msn.com and search on IP adres of your server.
     
  8. h4f

    h4f Well-Known Member

    Joined:
    Jun 5, 2007
    Messages:
    63
    Likes Received:
    0
    Trophy Points:
    6
    Indeed. Please keep in mind that it is 1000 * 100 concurrent. Something which a normal webserver will never have to proces.

    SuPHP is the problem, it doesn't fork a proces but ends the process as soon if the PHP code is processed. So refresh that site (F5) will start a new process that reads from disk again.
    SuPHP can only be fast if the PHP sites are located on a RAMDISK, but even then each process overhead time (start, process, end) will provide some latency.
     
  9. kampret

    kampret Member

    Joined:
    Jun 21, 2007
    Messages:
    20
    Likes Received:
    0
    Trophy Points:
    1
    I just run it daily, or more if my user/s ask for that (especially for joomla users).
    I realized that DSO is totally unsecure.... It makes me really depends on mod_security and php disable_functions values.
    Because changing to another php handler will be surelly brokes many sites inside my current DSO server.

    Or.. do you have another best idea to solve this, bro?
    What's your best suggestion for this dilemmatic php handlers?
    DSO = no.
    So?
    SuPHP seems not fast enough... and CPU killer either?
    FCGI?
    CGI?

    Thanks :)
     
  10. h4f

    h4f Well-Known Member

    Joined:
    Jun 5, 2007
    Messages:
    63
    Likes Received:
    0
    Trophy Points:
    6
    With CPanel support on newcreated users ( server/~account) php tmp dir in user home etc..

    And there is no difference with DSO.
     
  11. StingRay2k01

    StingRay2k01 Active Member

    Joined:
    Jun 15, 2003
    Messages:
    31
    Likes Received:
    1
    Trophy Points:
    6
    cPanel Access Level:
    Root Administrator
    Maybe I'm missing something, but how do they do this if open_basedir is enabled?

    I run a shared server with mod_php and am setting up another and investigating different options, so I'm interested in someone answering this hole in my knowledge. I'm not a hacker so i don't know how they can take an insecure script and use it to deface all the other sites on a server with open_basedir in effect...

    If someone is able to compromise an account though a script (external attack), what is the risk to the server as a whole if open_basedir is enabled and dangerous functions are disabled?
     
  12. sandi123

    sandi123 Member

    Joined:
    Mar 17, 2009
    Messages:
    5
    Likes Received:
    0
    Trophy Points:
    1
    php scripts loaded Server cpanel

    php scripts loaded Server cpanel.OS FREEBSD
    what to do?
     
  13. DReade83

    DReade83 Well-Known Member

    Joined:
    Oct 20, 2006
    Messages:
    196
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Cheshire, UK
    Sounds like you've not configured it right.

    FastCGI is fairly easy to deploy IMO... I did it a second ago for the first time in just a few minutes with absolutely zero FCGI experience.

    The HTTP 500 errors can be cured by reviewing your error_log file (see "/usr/local/apache/logs/error_log"). In my case I was using php_value in the htaccess file - I simply moved them into the main php.ini, but you can do this on a per-domain basis by using a php.ini in the root of your site.

    Apart from that, my server is now using FCGI with no drops in performance. It's also instantly secure because there's now a "php5" process running under each username, instead of "nobody". To test this I sent a simple email via mail() to my email address and in the headers where it usually says "nobody" it stated the username it was sent under - perfect!

    My server is also running eAccelerator, SuHosin and Mod Security, and works under FastCGI no problem.

    Best thing EVER is I didn't need to make any changes to my company's current site averaging 50,000 lines of code. It just worked from the off, no problems.
     
  14. fujipadam

    fujipadam Member

    Joined:
    Jun 25, 2009
    Messages:
    23
    Likes Received:
    0
    Trophy Points:
    1
    mpm-itk

    Has anyone tried out mpm-itk and does it work with any of the opcode cachers?

    Fuji
     
Loading...

Share This Page