Apache + php-fpm/FastCGI => php_flag/value issues

[HarmoniousVibe]

Ik ben laatst wat aan het experimenteren gegaan met php-fpm als vervanger voor het inefficiënte mod_php. Het lijkt erg goed te werken, op één ding na: er wordt domweg een http 500 opgeworpen als er ergens in een .htaccess een php_flag / php_value wordt gedefinieerd. Nu weet ik dat hiervoor de .user.ini moet worden gebruikt, maar het probleem is een beetje dat bijna alle PHP-software (zelfs Debian-packages als phpmyadmin) wordt geleverd met een .htaccess met daarin één of meerdere php_value-definities.

Is het mogelijk om php_flag/value gewoon te laten negeren in plaats van dat er een 500 wordt opgeworpen? Meestal zijn het toch gewoon memory_limit overrides, welke in principe niet nodig zijn met sane global defaults en voor de instellingen die wel nuttig zijn kan ik de gebruikers wel gewoon informeren en desnoods een scriptje schrijven wat de php_values in een .htaccess automatisch omzet naar een .user.ini.

[HollowGamer]

Zelfde probleem hier ook gehad. Je kunt de lijn weghalen of in comment zetten.
Er kunnen wel problemen ontstaan, zo zijn er vaak paden in gedefineerd.

Er zijn oplossingen voor, zoeken via Google vind je verschillende oplossingen.

[jb044]

Als het netjes gediefineerd is staat het in deze vorm:

code:

<IfModule mod_php5.c>
  php_value x y
</IfModule>

En de fout is van apache en terecht: je defineert een niet bestaande optie.

Workaround zou kunnen zijn om mod_php wel te laden maar niet te gebruiken, kost wat geheugen, maar als je het hebt en perse niet .htaccess files wilt editten is dat een optie.

[Kees]

Even een beetje offtopic maar:

inefficiënte mod_php.

In al mijn tests is mod_php nog steeds een stuk sneller dan welke andere php variant ook.

[jb044]

Kees schreef op zondag 02 december 2012 @ 20:52:
Even een beetje offtopic maar:

[...]

In al mijn tests is mod_php nog steeds een stuk sneller dan welke andere php variant ook.

Ook als je gaat schalen? Dat 1 simpel scriptje in 2 ms laadt of 3ms vind ik persoonlijk helemaal niet zo interessant.

[HarmoniousVibe]

jb044 schreef op zondag 02 december 2012 @ 17:40:
Als het netjes gediefineerd is staat het in deze vorm:

code:

<IfModule mod_php5.c>
  php_value x y
</IfModule>

En de fout is van apache en terecht: je defineert een niet bestaande optie.

Workaround zou kunnen zijn om mod_php wel te laden maar niet te gebruiken, kost wat geheugen, maar als je het hebt en perse niet .htaccess files wilt editten is dat een optie.

Heb je helemaal gelijk in. Echter is de realiteit dat dit soort dingen vaak niet in een dergelijk conditioneel blok worden gezet.

Het voor niets laden van mod_php 'defeats the purpose', gezien het feit dat de PHP-interpreter dan nog voor elk request moet worden ingeladen.

Kees schreef op zondag 02 december 2012 @ 20:52:
Even een beetje offtopic maar:

[...]

In al mijn tests is mod_php nog steeds een stuk sneller dan welke andere php variant ook.

Het gaat mij zoals jb044 als zei niet om pure performance, maar om de schaalbaarheid. Zowel omhoog als omlaag. Ik heb een aantal kleine VPS'jes met erg weinig geheugen en een aantal grote clusters met een vrij hoge load. Op termijn wil ik voor beide gevallen over op Varnish, maar tot ik daar voldoende mee heb getest bem ik aan het overwegen op over te stappen op PHP-FPM.

Op mijn één van mijn VPS'jes knalt apache er regelmatig uit als er veel zoekrobots langkomen . En op mijn clusters (voornamelijk met Magento) is het performanceverschil nagenoeg nihil, omdat de bottleneck daar bij Magento zelf ligt. Het verschil is wel dat er met PHP-FPM significant minder geheugen wordt verspild. Vandaar dus.