vertraging 1 minuut tussen file upload en apache?

[draadje]

Ik heb een vps "waar niets mis mee is" (wellicht niet van belang maar: centos6, directadmin).
Recentelijk een nieuwe vps (zelfde vps provider) besteld met standaard pakket: centos7, directadmin.

Laten we ze noemen vps1 (oude) en vps2 (nieuwe) .
Op vps1: draait domein1.nl, op vps2: domein2.nl.

Zonder ook maar één ding te wijzigen (na door de vps provider aangeleverde basisinstallatie*) vertoond vps2 een vreemde eigenschap. Waar ik met zoeken op het net geen oplossing voor kan vinden.

Het probleem: een wijziging in een webpagina is niet meteen online beschikbaar. De wijziging komt tussen de 0 en 59 seconde later door.

Wat ik doe:
1. in twee tabs van een webbrowser** open ik twee pagina's domein1.nl/pagina.php en domein2.nl/pagina.php
2. ik wijzig de webpagina*** in vps1, én ik wijzig in vps2 ook de webpagina*
3. ik upload beide gewijzigde webpagina's naar de verschillende vps'en / domeinen (en zie dat de tijdstempel zich netjes aanpast, dus de gewijzigde files staat remote "klaar")
4. ik refresh**** beide tabs in de webbrowser

Het resultaat:
- de pagina die van vps1 komt laat de gewijzigde inhoud meteen zien
- de pagina die van vps2 komt laat de gewijzigde inhoud doorgaans niet zien (zou toeval zijn) maar pas nadat een bepaald moment "in de minuut" voorbij is. Als ik een klok in de gaten hou ben ik er achter gekomen dat steevast de gewijzigde inhoud pas getoond wordt als (op mijn klokje) de secondewijzer op 5 staat. Dus in de praktijk krijg ik maar eens per minuut een update van gewijzigde files te zien.

het is 100% reproduceerbaar, met verschillende bestanden (ook wijzigingen in css files komen pas na een minuut door) en op verschillende domeinen op dezelfde vps2.

In welke richting moet ik zoeken?

*vps1: centos6 apache directadmin, vps2: centos7 apache directadmin (ik installeer niets, ik "krijg" een standaard pakket aangeboden).
** getest met firefox, chrome, edge, ie11, opera, ....
*** de inhoud van de pagina blijkt geen rol te spelen, ik heb het teruggebracht tot letterlijk alleen <p>tekst</p> zelfs zonder <html> etc.
**** het maakt niet uit of ik ctrl-r of ctrl-f5 gebruik

[dennis0162]

Php opcache wellicht? Of een andere vorm van caching.

[t.bloo]

php caching

staat op vps2 soms php7?

[draadje]

dennis0162: heel veel dank; tis opgelost.

Nooit geweten dat opcache default aan stond, in de centos6 installatie van mijn provider staat hij uit, centos7 dus aan (nooit mee gewerkt en niet bij stil gestaan).

Wat ik heb gedaan: in php.ini deze regel:
;opcache.enable=0

gewijzigd in:
opcache.enable=0

daarna httpd herstart.
Nog voor en na gecontroleerd met phpinfo() en daarmee ging hij van enabled naar disabled.

Nu worden wijzigingen direct weer zichtbaar.

Als ik later "in productie ga" zet ik die cache natuurlijk aan (nu ik weet dat hij er in zit)
Kan eventueel (nog geen praktische ervaring maar het kan niet missen) spelen met opcache.revalidate_freq=30 (of een andere waarde in seconde ligt er aan hoe lang ik wil wachten...)
t.bloo: ja maar ook in php 5.x had ik het probleem

[xleeuwx]

Opcache kan inderdaad het probleem zijn en dit soort installaties zijn ook gericht op productie omgevingen.

[draadje]

Opcache *is* de oorzaak.

Dat dit in productieomgevingen aan staat wil ik geloven en lijkt me heel wenselijk, maar dan verwacht je wel een consequent beleid bij een en dezelfde provider.

Bij de bewuste provider heb ik door de tijd meerdere vps'en aanschaft en daar is opcache niet ingeschakeld.
Bij diezelfde provider heb ik recentelijk nog (exact dezelfde) vps aanschaft en dan verwacht je dat ook dan opcache niet ingeschakeld is.
Althans dat is mijn verwachtingspatroon.
Dat bleek dus niet het geval, de laatste vps had opcache standaard enabled bleek achteraf.

Ik moet wel heel eerlijk zijn, wellicht is dit een beperking van mijn kennis. Het verschil tussen de twee vps typen in kwestie is een centos6 en centos7 installatie, wellicht dat het standaard met centos7 aan staat. En dan ligt de fout bij mij.

Natuurlijk heb ik eerst een issue gelogd bij de provider, maar daar werd ik met een kluitje in het riet gestuurd, de eerste reactie was: ligt waarschijnlijk aan caching in je webbrowser. Dat kon natuurlijk niet als ze mijn issue goed hadden gelezen, daarin stond vrijwel letterlijk hetzelde als de openingspost en die sluit het netwerk en alles aan de client kant uit.

Een beetje teleurgesteld was ik wel, hoewel ik verder niets te klagen heb over de bewuste provider.

Maar, ik ben wel heel erg blij met de reacties op dit forum.
Allen dank!

[CharlieRoot]

Opcache *is* de oorzaak.

Dat dit in productieomgevingen aan staat wil ik geloven en lijkt me heel wenselijk, maar dan verwacht je wel een consequent beleid bij een en dezelfde provider.

Bij de bewuste provider heb ik door de tijd meerdere vps'en aanschaft en daar is opcache niet ingeschakeld.
Bij diezelfde provider heb ik recentelijk nog (exact dezelfde) vps aanschaft en dan verwacht je dat ook dan opcache niet ingeschakeld is.
Althans dat is mijn verwachtingspatroon.
Dat bleek dus niet het geval, de laatste vps had opcache standaard enabled bleek achteraf.

Ik moet wel heel eerlijk zijn, wellicht is dit een beperking van mijn kennis. Het verschil tussen de twee vps typen in kwestie is een centos6 en centos7 installatie, wellicht dat het standaard met centos7 aan staat. En dan ligt de fout bij mij.

Natuurlijk heb ik eerst een issue gelogd bij de provider, maar daar werd ik met een kluitje in het riet gestuurd, de eerste reactie was: ligt waarschijnlijk aan caching in je webbrowser. Dat kon natuurlijk niet als ze mijn issue goed hadden gelezen, daarin stond vrijwel letterlijk hetzelde als de openingspost en die sluit het netwerk en alles aan de client kant uit.

Een beetje teleurgesteld was ik wel, hoewel ik verder niets te klagen heb over de bewuste provider.

Maar, ik ben wel heel erg blij met de reacties op dit forum.
Allen dank!

Zo te zien is dit default:
http://php.net/manual/en/opcache.configuration.php

Mogelijk had de andere installatie (CentOS 6) nog een oude PHP versie waar Opcache niet bij zat.