uphp vs fastcgi & eaccelerator

[h4f]

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/...figuration.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.

If not, it's also normal eA doesn't work because SuPHP run php as a child process under different users. eAccelerator needs all processes to be forked from the same parent to share a memory segment.

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.

[h4f]

                           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)

[kampret]

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/*

[kampret]

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

[dropby23]

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

[Infopro]

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.

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.

[h4f]

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/*

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.

[h4f]

Let me get this staight, you have one Joomla site on that server above, and get the loads you mention on all tests?

Indeed. Please keep in mind that it is 1000 * 100 concurrent. Something which a normal webserver will never have to proces.

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

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.

[kampret]

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.

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

[h4f]

FCGI?

With CPanel support on newcreated users ( server/~account) php tmp dir in user home etc..

And there is no difference with DSO.

[StingRay2k01]

...
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 process doesn't protect you from that.
...

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?

[sandi123]

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

[DReade83]

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/*

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.

[fujipadam]

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

Fuji