stay far from suphp !!

[manuk]

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

 

[dwykofka]

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

 

[manuk]

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.

 

[dwykofka]

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.

 

[manuk]

well on a server with pentium 4 and 150 account you will see the difference , and it's a big diffrence .

 

[jayh]

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.

 

[VeZoZ]

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.

 

[manuk]

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

 

[darren.nolan]

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).

 

[manuk]

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

 

[owine]

I am using Zend Optimizer, eAccelerator, Suhosin and suPHP with Apache 2 on a Pentium D and I see no performance issues.

 

[manuk]

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.

 

[DigitalN]

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