[PHP] Opcache op grote vps

[afraca]

Er zijn op internet tal van sites te vinden die Opcache tutorials hebben met hoe je het aanzet en dergelijke. Je hebt ook mensen die toegeven dat er niet heel veel documentatie over is:
https://www.scalingphpboo...e-settings-tuning-config/

Wij zitten met het probleem dat we een vps hebben waar tientallen sites op draaien, allemaal redelijk low-volume (daarom kan het nog op één redelijk krachtige VPS). Maar er komen problemen als je opcache dan wilt gebruiken.

Laatst probeerden we wat met een aardig grote cache size en dergelijke, maar je krijgt een interessante error als je gewoon niet al je files kan cachen voor zover wij merkten, namelijk
white page of death...
(Dit is eigenlijk nog best een interessant issue, mocht je ideeën hebben hoor ik het graag. In de opcache error log kwam in ieder geval niet iets te staan de afgelopen keer. Het repliceren is nogal een lastige boel helaas )

De performance gains zijn echter significant, 10x zo snel is niet ongehoord.... Hoe kunnen we dit nou handig aanpakken? We hebben beperkte cache capaciteit uiteraard.

edit: Op vps staan momenteel 137k php bestanden.

[RobIII]

afraca schreef op woensdag 16 december 2015 @ 15:22:
edit: Op vps staan momenteel 137k php bestanden.

HOLY... Well... there's your problem...
Ik zou eens beginnen met 't opschonen daarvan, overbodige meuk eruit etc. En dan opsplitsen in meerdere servers met enkele sites waar mogelijk.

Overigens kun je ook eens spelen met de opcache.max_accelerated_files optie; ik lees nergens terug of je dat al geprobeerd hebt? Wat waren de andere settings waar jullie mee gespeeld hebben?

afraca schreef op woensdag 16 december 2015 @ 15:22:
We hebben beperkte cache capaciteit uiteraard.

Tja, voor een duppie op de eerste rang willen zitten, een server tot aan de nok toe vol gooien en dan raar vinden dat er weinig speelruimte over is. Waarom is hier niet al veel eerder gekozen voor een tweede (derde, ...) server? Zoiets zie je toch van mijlen ver aankomen?

afraca schreef op woensdag 16 december 2015 @ 15:22:
Laatst probeerden we wat met een aardig grote cache size en dergelijke, maar je krijgt een interessante error als je gewoon niet al je files kan cachen voor zover wij merkten, namelijk
white page of death...

En het is 100% uitgesloten dat 't aan de opcache lag en dat er geen andere oorzaak was? Hoe is dat bepaald? Zéker als er niets staat in de opcache logs; is er dan wel in andere logs gekeken? Wat stond daar in?

[Voor 71% gewijzigd door RobIII op 16-12-2015 15:32]

[afraca]

-_- Soms is een muis met extra knoppen te gevaarlijk, hele reply weggegooid....

Hierbij alsnog de opcache die we geprobeerd hebben:

code:

zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20121212/opcache.so
;opcache.enabled=1
opcache.enable_cli=0
opcache.memory_consumption=512
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=3000
opcache.revalidate_freq=15
opcache.fast_shutdown=1
opcache.use_cwd=1
;opcache.save_comments=0
opcache.error_log='/var/log/opcache.log'

Ik heb zelf nog gedacht dat misschien de fast_shutdown nog gevaarlijk kon zijn. Zoals ik zei is het lastig te repliceren zonder de vps geheel onbereikbaar te maken met die 'white page of death'.

Anyway, over je server-opmerkingen. Je moet goed beseffen dat het hier gaat om ~50 sites, waarvan ~40 extreem gemodificeerde Wordpress sites zijn voor een meubelzaak in een klein stadje bij wijze van spreken. Met een bijbehorende Magento webshop erin gebouwd bijvoorbeeld. Die krijgen dan 2000 views per maand oid.

Qua serverload is het niet extreem voor zover ik weet. We hebben monitoring-software, en toen ik laatst meekeek gebruiken we 50% geheugen en 30% cpu of whatever, niet gekke dingen.

Extra servers betekent gewoon heel veel extra management, en welke baten? (Die baten zouden dus eventueel opcache iets zijn)

Oja, en we hebben nu een stuk of 10 sites in een Laravel installatie hangen. Per site is dat ongeveer 10k files. Ja, dan gaat het snel.....

[GlowMouse]

RobIII schreef op woensdag 16 december 2015 @ 15:26:
[...]

HOLY... Well... there's your problem...
Ik zou eens beginnen met 't opschonen daarvan, overbodige meuk eruit etc. En dan opsplitsen in meerdere servers met enkele sites waar mogelijk.

Wordpress bestaat al uit ruim 500 php files, Joomla uit 2400. Ik zie niet in waarom 137k enig probleem zou mogen opleveren. Ook zie ik niet waarom er naast performanceproblemen fouten mogen optreden als er te weinig geheugen voor de opcache wordt gereserveerd.
Helaas mist er veel info:
- wordt elke pagina wit?
- wat is de http status code?
- hoelang duurt het voordat de webserver reageert?
- heeft de server nog geheugen of swapruimte vrij?

[afraca]

Dit topic heeft per ongeluk twee onderwerpen gekregen, waarbij de één uit de ander voortkomt.

Over de Opcache problemen had ik zelf niet veel informatie gegeven, omdat m'n collega's konden begrijpen dat bij cacheruimte tekort er dingen foutgaan. Ikzelf was het met GlowMouse eens dat het dan gewoon goed zou moeten gaan.

Die situatie is ondertussen een maand geleden, en is dus lastig informatie over te geven, omdat ik niet zo makkelijk kan reproduceren.
[list]
• Server had nog geheugen
• Hoe lang: volgens mij binnen 100ms


Ik ga nadenken hoe ik hier meer informatie over kan geven!

Wordpress is trouwens 1300 bestanden, net even gechecked. Maar Laravel met een aantal packages is nog flink groter met 10.000

[Voor 10% gewijzigd door afraca op 16-12-2015 16:10]

[Ultimation]

Je zou je server beheer niet zelf willen doen. Laat dit aan een toko over die weet wat ze doen. Zakelijk heb ik goede ervaring met Exonet.

[afraca]

Ultimation schreef op woensdag 16 december 2015 @ 16:14:
Je zou je server beheer niet zelf willen doen. Laat dit aan een toko over die weet wat ze doen. Zakelijk heb ik goede ervaring met Exonet.

We zitten bij CloudVPS

[Ultimation]

afraca schreef op woensdag 16 december 2015 @ 16:14:
[...]


We zitten bij CloudVPS

Wat voor SLA heb je daar? In plaats van zelf te klooien zou ik de vraag bij hun neerleggen.

[mithras]

Veel heeft te maken met instellingen en verbruik. Wij gebruikten ook CloudVPS, daar is niks mis mee. Je hoeft hen ook niet in te schakelen, zolang je weet wat je doet.

Qua instellingen heb je de relevante config gegeven. Verbruik mist nog een hoop. Check eens de status met ocp.php en wat je verbruik is. Let namelijk op dat je totaal bestaat uit cache, waste en leeg. Cache invalidatie is een lastig issue met php opcache. Aantal bestanden, grootte van cache en mate van refresh is best relvant om je verder te helpen.

[Ultimation]

mithras schreef op woensdag 16 december 2015 @ 16:20:
Veel heeft te maken met instellingen en verbruik. Wij gebruikten ook CloudVPS, daar is niks mis mee. Je hoeft hen ook niet in te schakelen, zolang je weet wat je doet.

Niet om afraca af te vallen, maar als hij dat had geweten had hij de vraag hier niet hoeven stellen. Daarbij is hij er inmiddels een tijdje mee bezig, tijd die ook aan commerciële projecten had kunnen worden besteed. Wanneer je nu dus een goede SLA had gehad, had je een e-mail naar de hostingprovider in kwestie gestuurd en was het met 5 minuten opgelost. Nu is hij er (afgaande op de tijd van de topicstart) al een uurtje mee bezig.

[RobIII]

GlowMouse schreef op woensdag 16 december 2015 @ 16:04:
Wordpress bestaat al uit ruim 500 php files, Joomla uit 2400. Ik zie niet in waarom 137k enig probleem zou mogen opleveren.

Dat zijn dus 57 joomla installaties of 274 Wordpress installaties. Op. Eén. Server. En dat vind je normaal? Nu ben ik er al een poosje "uit" (niet dat ik er ooit "in" ben geweest ) en hardware van tegenwoordig doet 't wat beter dan destijds, maar voor mij voelt 't als "(veel) te veel" maar dat is natuurlijk ook afhankelijk van hoeveel pageviews/bezoekers etc. je sites doen. Maar goed; wat ik altijd en overal roep: meten == weten. 137.000 "voelt" voor mij iig als bizar veel, maar misschien zit ik er daar dus anno 2015 een beetje langs

GlowMouse schreef op woensdag 16 december 2015 @ 16:04:
Ook zie ik niet waarom er naast performanceproblemen fouten mogen optreden als er te weinig geheugen voor de opcache wordt gereserveerd.

Omdat niet alle PHP's in de cache passen en de oudste* eruit gemikkerd worden (FIFO) waardoor, met een beetje pech, de frontpage van een joomla die 1000+ PHP files aantikt meteen de helft van je cache (bij de default setting van 2000, vandaar dat ik er naar vroeg) invalideert / onbruikbaar maakt voor de rest van je 50+ sites

* langst geleden gecached en/of langst geleden gebruikt natuurlijk

[Voor 24% gewijzigd door RobIII op 16-12-2015 16:34]

[kwaakvaak_v2]

afraca schreef op woensdag 16 december 2015 @ 15:57:
-_- Soms is een muis met extra knoppen te gevaarlijk, hele reply weggegooid....

Hierbij alsnog de opcache die we geprobeerd hebben:

code:

zend_extension=/usr/local/lib/php/extensions/no-debug-non-zts-20121212/opcache.so
;opcache.enabled=1
opcache.enable_cli=0
opcache.memory_consumption=512
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=3000
opcache.revalidate_freq=15
opcache.fast_shutdown=1
opcache.use_cwd=1
;opcache.save_comments=0
opcache.error_log='/var/log/opcache.log'

.

Maar in die config staat opcache uit?

Je max accelerated moet met zoveel bestanden omhoog. En als het vooral php files zijn die nooit veranderen zijn zou je eventueel de checks uit kunnen zetten.

code:

opcache.revalidate_freq=0
opcache.validate_timestamps=0

En je zou even kunnen spelen met meer geheugen aan opcache.interned_strings_buffer toekennen.

Maar weet je wel heel zeker dat het opcache is die eruit vliegt? En wat zegt je syslog dan? Kan ook een ander issue zijn wat toevallig getriggerd wordt door een opcache memory fault.

[GlowMouse]

RobIII schreef op woensdag 16 december 2015 @ 16:27:
[...]

Omdat niet alle PHP's in de cache passen en de oudste* eruit gemikkerd worden (FIFO) waardoor, met een beetje pech, de frontpage van een joomla die 1000+ PHP files aantikt meteen de helft van je cache (bij de default setting van 2000, vandaar dat ik er naar vroeg) invalideert / onbruikbaar maakt voor de rest van je 50+ sites

* langst geleden gecached en/of langst geleden gebruikt natuurlijk

Zou kunnen, en dan loop je wellicht tegen mutex contention aan bij het updaten van de cache, maar dat zou je in het cpu-gebruik en de responstijd moeten terugzien. Ook verwacht je de problemen vrijwel direct als je de server met opcode cache aanzet, terwijl repliceren toch lastig blijkt te zijn.

[Gomez12]

RobIII schreef op woensdag 16 december 2015 @ 16:27:
[...]
Dat zijn dus 57 joomla installaties of 274 Wordpress installaties. Op. Eén. Server. En dat vind je normaal?

Welkom in de wondere wereld van budgethosting (niet denigrerend bedoeld tegenover TS)

Als je als bedrijf een webhosting plek aanbied voor 1 tot 5 euro per maand dan zal je er eigenlijk nog wel wat meer joomla's naast moeten zetten om het financieel rendabel te houden.

Ik heb geen idee of TS webhosting aanbied voor die prijzen, maar ik ken wel partijen die dat doen en die laten rustig 500 klanten op 1 server staan (zo niet meer)

[TimDJ]

Je kan om te testen natuurlijk even tijdelijk een kopie maken van de server! Revalidate uitzetten zoals hierboven gezegd wordt is vragen om problemen.

Is het niet mogelijk om alleen de drukste sites te cachen of op een losse vps te zetten?

[Acid_Burn]

RobIII schreef op woensdag 16 december 2015 @ 16:27:
[...]

Dat zijn dus 57 joomla installaties of 274 Wordpress installaties. Op. Eén. Server. En dat vind je normaal? Nu ben ik er al een poosje "uit" (niet dat ik er ooit "in" ben geweest ) en hardware van tegenwoordig doet 't wat beter dan destijds, maar voor mij voelt 't als "(veel) te veel" maar dat is natuurlijk ook afhankelijk van hoeveel pageviews/bezoekers etc. je sites doen. Maar goed; wat ik altijd en overal roep: meten == weten. 137.000 "voelt" voor mij iig als bizar veel, maar misschien zit ik er daar dus anno 2015 een beetje langs

De website waar ik op dit moment mee bezig ben heeft bijna 31K bestanden. Dat is 1 website, wel op basis van Symfony2.

[InZane]

Acid_Burn schreef op donderdag 17 december 2015 @ 13:03:
[...]

De website waar ik op dit moment mee bezig ben heeft bijna 31K bestanden. Dat is 1 website, wel op basis van Symfony2.

31K voor een freakin' website?
Dat mag wel een hele beste site a la Wehkamp zijn dan.

[kwaakvaak_v2]

Acid_Burn schreef op donderdag 17 december 2015 @ 13:03:
[...]

De website waar ik op dit moment mee bezig ben heeft bijna 31K bestanden. Dat is 1 website, wel op basis van Symfony2.

Ik schrik daar ook niet echt van, zeker met moderne PHP heb je vaak een Interface en of Abstract class en dan de verschillende varianten.

Zelf in een 'ouderwetse' Drupal 7 installatie heb ik als ruim 10.000 files met <?php... erin. En daar draaien er ook meerdere van op 1 server. Juist daar helpt opcache ons gigantisch bij, alleen ik heb wel meer geheugen toe moeten kennen aan opcache. Maar dat was een kwestie van paar weken monitoren en loggen op het gebruik vs cache miss en hits en spelen met TTL waardes. En heel bewust bepaalde directories in een paar projecten juist niet door opcache laten gaan. Vooral met stukjes code die bijv alleen voor backend dingen gebruikt worden. 95% van het verkeer zijn anonieme bezoekers, die moeten een snelle site krijgen. Een admin kan best een beetje langer wachten op een request.

Edit.. Ik weet het niet 100% zeker meer, maar ik meen dat ik deze https://bitbucket.org/sking/newrelic-phpopcache/overview poosje mee heb laten lopen op 1 van de VPS'e in de NewRelic monitoring (overigens ook blij Cloudvps, bare centos 7 en dan alleen mariadb, memcached, php-fpm en apache 2.4 erop)

[Voor 12% gewijzigd door kwaakvaak_v2 op 17-12-2015 13:36. Reden: newrelic]

[Voutloos]

RobIII schreef op woensdag 16 december 2015 @ 16:27:
Omdat niet alle PHP's in de cache passen en de oudste* eruit gemikkerd worden (FIFO) waardoor, met een beetje pech, de frontpage van een joomla die 1000+ PHP files aantikt meteen de helft van je cache (bij de default setting van 2000, vandaar dat ik er naar vroeg) invalideert / onbruikbaar maakt voor de rest van je 50+ sites

* langst geleden gecached en/of langst geleden gebruikt natuurlijk

Logisch als je het verwacht, maar zo werkt de opcache helaas niet eens.

Eviction is in de zend opcache zo lui mogelijk geimplementeerd (iit APC, of andere projecten waar het meestal ongemerkt sexy werkt als Memcached). Er is geen fancy LRU, enkel een paar heuristieken wanneer t herstart, zie https://github.com/zendtech/ZendOptimizerPlus/issues/187

Hier lopen wij ook tegenaan: Nieuwe versies zetten wij naast de oude. Oude scripts bestaan nog maar worden dan niet aangeroepen. Deze opzet zorgt er alleen soms voor dat de opcache niets met de nieuwe (huidige!) PHP files doet.

De mutex contention die GlowMouse verwacht is er dus ook niet.

Overigens is dit allemaal misschien offtopic. TS is er niet duidelijk in of het niet gewoon een ordinaire segfault is.

[Voor 8% gewijzigd door Voutloos op 17-12-2015 13:38]

[Acid_Burn]

InZane schreef op donderdag 17 december 2015 @ 13:29:
[...]


31K voor een freakin' website?
Dat mag wel een hele beste site a la Wehkamp zijn dan.

Ik werk aan een site waar de mensen van de serviceafdeling van (o.a.) MediaMarkt mee werken.

[storeman]

Terug on topic.

Wij gebruiken opcache ook al jaren en hebben dit probleem nog steeds wel eens. Ik heb geen exacte oplossing, maar wel een aantal suggesties/constateringen (overigens is dit met APC, maar het WSoD is heel herkenbaar):

- De use_cwd optie moet je volgens mij uitzetten. Met zoveel bestanden wil je gewoon de absolute paden opslaan en niet de relatieve. Sommige relatieve paden kunnen namelijk hetzelfde zijn, waardoor er misschien verkeerde versies van bestanden worden gebruikt
- Na een update van een PHP-file, herstart ik altijd apache (of reload, iets vriendelijker). Ik ga ervan uit dat je mod_php draait in Apache. Dit lost het probleem met de witte schermen op, na gewijzigde PHP files

Verder nog een suggestie, vraag of CloudVPS je machine wil klonen, zodat je kan experimenteren zonder dat je alles om zeep helpt.

Ohja, wij hebben CloudVPS zo goed als verlaten, wat een belabberde hoster is dat. Ze zijn wel scherp geprijst voor snelle servers, maar er is ook regelmatig wat aan de hand. [/bash]

[Voor 19% gewijzigd door storeman op 19-12-2015 08:23. Reden: Onzin verwijderd.]