Php4 & Php5

[TechXP]

Ik las dat men PHP4 en PHP5 op een server naast elkaar kan draaien. Iemand dat al gedaan?

Mijn control panel wil ik in PHP 5 schrijven (vanwege OOP), maar ik wil het liefst ook nog voor een aantal accounts gebruik maken van PHP4.

Nu vraag ik me af of iemand hier dat al draait naast elkaar en of het problemen oplevert.
En of de performance van de server goed blijft als je accounts hebt met php5 en met php4?

groet,

Alex

[Triloxigen]

Je dient dan de PHP gegevens in de httpd.conf niet direct in de conf te plaatsen, maar in de <virtualhost> container.

[Cybafish]

Wij doen dit al sinds oktober vorig jaar. Gewoon php5 als apache module laten draaien (apxs) en php4 aanroepen via CGI Dan kunnen mensen hun scripts gewoon renamen naar .php5 en wordt het door de php5 engine afgehandeld...

[TechXP]

En hoe zit het qua performance? Als cgi aanroepen is toch intensiever?

[Cybafish]

Neuh, we deden dit sowieso al i.v.m. suPHP, het verscil is nauwelijks merkbaar.

[TechXP]

ok bedankt. dan ga ik ook beide doen

[MikeN]

Het verschil tussen aanroepen via CGI en aanroepen als apache module is in mijn metingen ongeveer een factor 20 (maar dat is dan nog met suPHP overhead erbij, dus puur als CGI zal het wsl iets lager zijn, factor 15 ofzo ) Zolang je niet teveel PHP pagina's hebt moet dit wel te doen zijn, maar ik denk niet dat het iets is wat je graag wil volhouden met veel dynamische sites.

[Cybafish]

Onderbouw het even met concrete statistieken, want dat dingen jou 'lijken' is allemaal prima, maar ik heb gewoon geen enkele affiniteit met lijkende dingen, ik ben meer van de concrete resultaten

[MikeN]

Sorry, ik heb helaas geen keiharde cijfers voor je Deze uitspraken zijn puur gebaseerd op metingen die ik ooit heb gedaan om de performance van een suPHP install te vergelijken met die van een installatie waarbij PHP als module draaide. Het enige wat ik er nog van weet is dat suPHP ongeveer een factor 20 trager was (in aantal requests per seconde met verschillende apachebench instellingen) Het is echter niet getest in een productieomgeving, met verschillende PHP scripts of ook maar enigsinds reproduceerbaar opgeschreven. Het was puur om even aan te geven dat in mijn ogen het verschil tussen PHP als module of PHP als CGI wel degelijk merkbaar is, of het in jouw persoonlijke situatie ook echt merkbaar is of, nog belangrijker, een probleem wordt, is nog maar te bezien

[resellerhostnl]

Origineel geplaatst door Cybafish
Onderbouw het even met concrete statistieken, want dat dingen jou 'lijken' is allemaal prima, maar ik heb gewoon geen enkele affiniteit met lijkende dingen, ik ben meer van de concrete resultaten

Ik kan in iedergeval melden dat ik met suPHP elk weekend twee vastlopers had, en een load altijd rond de 2.50, met php als module heb ik een load van 0.40 gemiddeld en nooit meer problemen.

[yourforum]

ik ben heel benieuwd of hier goede 'howtos' van zijn

[Cybafish]

Origineel geplaatst door resellerhostnl


Ik kan in iedergeval melden dat ik met suPHP elk weekend twee vastlopers had, en een load altijd rond de 2.50, met php als module heb ik een load van 0.40 gemiddeld en nooit meer problemen.

# uptime && php -v
09:18:25 up 20 days, 15:18, 2 users, load average: 0.41, 0.44, 0.29

PHP 4.3.10 (cgi) (built: Feb 1 2005 20:17:54)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
with Zend Extension Manager v1.0.6, Copyright (c) 2003-2004, by Zend Technologies
with Zend Optimizer v2.5.7, Copyright (c) 1998-2004, by Zend Technologies

Tja, jou tell me, draait zo stabiel als het maar kan. Dit is een server met pakweg 250 actieve domeinnamen.

Wat je wel in overweging moet nemen is dat suPHP het monitoren van je gebruikers een stuk eenvoudiger en efficiënter maakt, hetgeen uiteindelijk weer personeelskosten scheelt. Of je nu dus voor een handvol accounts in zo'n geval één of twee servers moet draaien, dat is een afweging die je zelf moet maken.

[maxnet]

I.p.v. CGI kan je ook FastCGI gebruiken.
Hierbij is de performance vergelijkbaar met mod_php.

Wij hebben voor eigen gebruik ook een andere PHP versie dan voor gebruikers.


Als volgt gedaan:

- PHP met de --with-fastcgi optie compileren.
- mv php /usr/local/www/cgi-bin/phpf
- httpd.conf aangepast.

LoadModule fastcgi_module   libexec/apache2/mod_fastcgi.so
FastCgiServer /usr/local/www/cgi-bin/phpf
Action php-fastcgi /cgi-bin/phpf

<Directory /users>
        AddHandler php-fastcgi .php 
</Directory>

[maxnet]

Origineel geplaatst door resellerhostnl

Ik kan in iedergeval melden dat ik met suPHP elk weekend twee vastlopers had, en een load altijd rond de 2.50, met php als module heb ik een load van 0.40 gemiddeld en nooit meer problemen.

Loadavg geeft aan hoeveel processen tegelijk actief zijn (niet slapen).
Bij CGI zijn dat er altijd meer (1 proces voor de webserver, 1 voor PHP) dan bij modphp (1 proces voor beide).

Dit wil echter niet perse zeggen dat deze processen ook daadwerkeiljk een hoog CPU verbruik hebben.


Voorbeeld, een server voor een van mijn eigen (hobby) websites:

 04:34:56  up 20 days,  1:49,  2 users,  load average: 96.21, 68.14, 39.41

Loadavg aan de hoge kant.
CPU verbruik is echter nagenoeg niks:

CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
           total    9.0%    0.0%    4.0%   0.0%     0.0%    0.0%   86.9%

[resellerhostnl]

Origineel geplaatst door maxnet


Loadavg geeft aan hoeveel processen tegelijk actief zijn (niet slapen).
Bij CGI zijn dat er altijd meer (1 proces voor de webserver, 1 voor PHP) dan bij modphp (1 proces voor beide).

Dit wil echter niet perse zeggen dat deze processen ook daadwerkeiljk een hoog CPU verbruik hebben.


Voorbeeld, een server voor een van mijn eigen (hobby) websites:

 04:34:56  up 20 days,  1:49,  2 users,  load average: 96.21, 68.14, 39.41

Loadavg aan de hoge kant.
CPU verbruik is echter nagenoeg niks:

CPU states:  cpu    user    nice  system    irq  softirq  iowait    idle
           total    9.0%    0.0%    4.0%   0.0%     0.0%    0.0%   86.9%

Dat is inderdaad waar, maar ook kwa vastlopers heb ik nu nooit problemen meer.