realpath-Cache abschalten

3 views
Skip to first unread message

Stefan Froehlich

unread,
Jan 26, 2021, 7:39:53 AMJan 26
to
Seit ich auf meinem größten Server von PHP7.0 auf PHP7.3 umgestiegen
bin (ich weiss, ein bisschen arg spät, aber wer im Jahr 2005 eine
Klasse "Object" nennt, muss im Jahr 2020 halt leiden), nervt mich
das deutlich agressivere Caching von PHP. Ich verwende symbolische
Links zum Umschalten der Software-Version einzelner vhosts, und das
macht seit dem Versionswechsel Probleme (sprich: Nach einer
Linkänderung ist meistens, aber nicht immer, auch ein Anschubsen des
Webservers nötig, damit der Wechsel erkannt wird).

Immerhin weiss ich inzwischen schon, woher das wohl kommt:
<https://blog.forrest79.net/?p=537>

Ideal wäre, wenn der Cache (nur) innerhalb eines Requests aktiv
wäre; 99%+ der eingebundenen Files liegen in einigen, wenigen
Verzeichnissen, deren einmalige Auflösung völlig irrelevant wäre.
Ich sehe an Konfigurationsmöglichkeiten jedoch nur
<https://www.php.net/manual/en/ini.core.php#ini.realpath-cache-size> und
<https://www.php.net/manual/en/ini.core.php#ini.realpath-cache-ttl>,
die beide request-übergreifend arbeiten. Das geht also offenbar
nicht.

Aber auch globales Deaktivieren (mit der schwächeren Performance
müsste ich halt leben) scheint schwierig zu sein; ich habe
inzwischen:

#v+
realpath_cache_size = 0
realpath_cache_ttl = -1
#v-

in meiner php.ini stehen (und das wird von phpinfo() bestätigt),
aber *trotzdem* verlangt der Webserver teilweise einen Schubs, bis
er einen geänderten Link an die Applikation weiterreicht.

Wie bekomme ich das weg?

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Bocken mit Stefan - schmierig werden mit Stil.
(Sloganizer)

Arno Welzel

unread,
Jan 26, 2021, 8:14:37 AMJan 26
to
Stefan Froehlich:

> Seit ich auf meinem größten Server von PHP7.0 auf PHP7.3 umgestiegen
> bin (ich weiss, ein bisschen arg spät, aber wer im Jahr 2005 eine
> Klasse "Object" nennt, muss im Jahr 2020 halt leiden), nervt mich
> das deutlich agressivere Caching von PHP. Ich verwende symbolische
> Links zum Umschalten der Software-Version einzelner vhosts, und das
> macht seit dem Versionswechsel Probleme (sprich: Nach einer
> Linkänderung ist meistens, aber nicht immer, auch ein Anschubsen des
> Webservers nötig, damit der Wechsel erkannt wird).
>
> Immerhin weiss ich inzwischen schon, woher das wohl kommt:
> <https://blog.forrest79.net/?p=537>
>
> Ideal wäre, wenn der Cache (nur) innerhalb eines Requests aktiv
> wäre; 99%+ der eingebundenen Files liegen in einigen, wenigen
> Verzeichnissen, deren einmalige Auflösung völlig irrelevant wäre.

Dann wäre der Cache aber überflüssig, da dann ohnehin alles direkt neu
geladen werden muss.

> Ich sehe an Konfigurationsmöglichkeiten jedoch nur
> <https://www.php.net/manual/en/ini.core.php#ini.realpath-cache-size> und
> <https://www.php.net/manual/en/ini.core.php#ini.realpath-cache-ttl>,
> die beide request-übergreifend arbeiten. Das geht also offenbar
> nicht.

Korrekt - denn beim Cache geht es ja gerade darum, die Daten über
mehrere Aufrufe hinweg vorzuhalten, damit die Scripte eben nicht
jedesmal neu gladen und interpetiert werden müssen.

> Aber auch globales Deaktivieren (mit der schwächeren Performance
> müsste ich halt leben) scheint schwierig zu sein; ich habe
> inzwischen:
>
> #v+
> realpath_cache_size = 0
> realpath_cache_ttl = -1
> #v-
>
> in meiner php.ini stehen (und das wird von phpinfo() bestätigt),
> aber *trotzdem* verlangt der Webserver teilweise einen Schubs, bis
> er einen geänderten Link an die Applikation weiterreicht.

Dann hat wohl der Server noch einen Handle offen. Denn mehr als
"realpath_cache_size = 0" kann man nicht machen, um den Cache
funktionslos zu machen.

> Wie bekomme ich das weg?

Nichts, außer die betroffenen Dienste neu zu starten.

Ist eine Downtime von ein paar Sekunden wirklich ein Problem? Dann würde
ich eine redundante Infrastruktur mir Load Balancer aufbauen, statt mit
Links im Dateisystem herumzubasteln, was IMHO einer eher untaugliche
Lösung für das Problem ist.


--
Arno Welzel
https://arnowelzel.de

Stefan Froehlich

unread,
Jan 26, 2021, 8:50:47 AMJan 26
to
On Tue, 26 Jan 2021 14:14:35 Arno Welzel wrote:
> Stefan Froehlich:
> > <https://blog.forrest79.net/?p=537>

> > Ideal wäre, wenn der Cache (nur) innerhalb eines Requests aktiv
> > wäre; 99%+ der eingebundenen Files liegen in einigen, wenigen
> > Verzeichnissen, deren einmalige Auflösung völlig irrelevant
> > wäre.

> Dann wäre der Cache aber überflüssig, da dann ohnehin alles direkt
> neu geladen werden muss.

Innerhalb eines Aufrufs werden ja hunderte require_once abgesetzt,
und die Auflösung der Dateinamen erfolgt (IIRC) komponentenweise. Es
macht also sehr wohl einen Unterschied, ob /a/b/c/d/e/ für jede
Datei einzeln aufgelöst werden muss, oder nur 1x pro Aufruf. Ich
weiss allerdings nicht, ob es innerhalb der einzelnen Aufrufe nicht
ohnehin noch einen weiteren, von realpath_cache unabhängigen Cache
gibt.

> > #v+
> > realpath_cache_size = 0
> > realpath_cache_ttl = -1
> > #v-

> > in meiner php.ini stehen (und das wird von phpinfo() bestätigt),
> > aber *trotzdem* verlangt der Webserver teilweise einen Schubs,
> > bis er einen geänderten Link an die Applikation weiterreicht.

> Dann hat wohl der Server noch einen Handle offen. Denn mehr als
> "realpath_cache_size = 0" kann man nicht machen, um den Cache
> funktionslos zu machen.

Ja, das hätte ich auch vermutet. Allerdings habe ich die obigen
Einstellungen über die Weihnachtsfeiertage vorgenommen und den
Apache seither aus anderen Gründen sicherlich ein Dutzend Mal neu
gestartet. Dennoch hat mich das gerade vor diesem Posting wieder
gebissen, und im Unterschied zu den letzten paar Wochen habe ich es
mir diesmal mit phpinfo() und zahlreichen hin/her-Switches genauer
angesehen.

> > Wie bekomme ich das weg?
>
> Nichts, außer die betroffenen Dienste neu zu starten.

Hm. Dann spukt es auf meinem Server.

> Ist eine Downtime von ein paar Sekunden wirklich ein Problem? Dann
> würde ich eine redundante Infrastruktur mir Load Balancer
> aufbauen, statt mit Links im Dateisystem herumzubasteln, was IMHO
> einer eher untaugliche Lösung für das Problem ist.

Die Downtime von ein paar Sekunden wäre vielleicht verschmerzbar,
aber das Procedere ist es nicht. Auf dem Server sind zwei Dutzend
vhosts, die im Grunde die gleiche Software verwenden, bei denen ich
aber gelegentlich auf Zuruf einen einzelnen ab- und auf einen
anderen Versionsstand umhänge. Zum einen möchte ich das nicht immer
als root tun müssen, zum anderen vergesse ich manchmal auch schlicht
auf den reload des Webservers, und dann passieren die lustigsten
Dinge.

Die Entscheidung "Cache weg" ist im Prinzip fix gefallen, nur
geschafft habe ich das noch nicht, und mir ist unklar, woran es
zur Zeit noch scheitert.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Für den sympathischen Halunken von Welt - rollen mit Stefan!
(Sloganizer)

Karl Pflästerer

unread,
Jan 26, 2021, 9:14:06 AMJan 26
to
Bist du sicher, dass es der realpath_cache ist? Was ist mit Opcache?

KP

Stefan Froehlich

unread,
Jan 26, 2021, 3:34:41 PMJan 26
to
On Tue, 26 Jan 2021 15:14:04 Karl Pflästerer wrote:
> Stefan...@Froehlich.Priv.at (Stefan Froehlich) writes:
> >> > #v+
> >> > realpath_cache_size = 0
> >> > realpath_cache_ttl = -1
> >> > #v-

> >> > in meiner php.ini stehen (und das wird von phpinfo()
> >> > bestätigt), aber *trotzdem* verlangt der Webserver teilweise
> >> > einen Schubs, bis er einen geänderten Link an die Applikation
> >> > weiterreicht.

> >> Dann hat wohl der Server noch einen Handle offen. Denn mehr als
> >> "realpath_cache_size = 0" kann man nicht machen, um den Cache
> >> funktionslos zu machen.
> >
> > Ja, das hätte ich auch vermutet. Allerdings habe ich die obigen
> > Einstellungen über die Weihnachtsfeiertage vorgenommen und den
> > Apache seither aus anderen Gründen sicherlich ein Dutzend Mal
> > neu gestartet. Dennoch hat mich das gerade vor diesem Posting
> > wieder gebissen, und im Unterschied zu den letzten paar Wochen
> > habe ich es mir diesmal mit phpinfo() und zahlreichen
> > hin/her-Switches genauer angesehen.
> >
> > Die Entscheidung "Cache weg" ist im Prinzip fix gefallen, nur
> > geschafft habe ich das noch nicht, und mir ist unklar, woran es
> > zur Zeit noch scheitert.

> Bist du sicher, dass es der realpath_cache ist? Was ist mit Opcache?

Hm. Das auf der im OP verlinkten Seite beschriebene Problem passte
einfach zu genau, als dass mich noch nach anderen Ursachen umgesehen
hätte. OpCache ist aktiviert und läuft mit den Defaultwerten
(sprich: die php.ini ist frei von jeglicher Einstellung); was davon
könnte das beobachtete Verhalten erzeugen? (Erwähnt werden sollte
hier evt., dass Änderungen in den Files *grundsätzlich* immer und
sofort übernommen werden; das Problem tritt nur beim Verbiegen von
Symlinks auf).

Dummerweise lässt sich das jetzt gerade nicht reproduzieren
(offenbar passiert das eher unter Last, was mir widersinnig
erscheint), ansonsten hätte ich es einmal ganz ohne OpCache
versucht.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan. Himmlisch und fanatisch!
(Sloganizer)

Stefan Froehlich

unread,
Feb 12, 2021, 3:09:41 PMFeb 12
to
On Tue, 26 Jan 2021 15:14:04 Karl Pflästerer wrote:
> Stefan...@Froehlich.Priv.at (Stefan Froehlich) writes:
> > On Tue, 26 Jan 2021 14:14:35 Arno Welzel wrote:
> >> Stefan Froehlich:
> >> > <https://blog.forrest79.net/?p=537>

> >> > #v+
> >> > realpath_cache_size = 0
> >> > realpath_cache_ttl = -1
> >> > #v-

> >> > in meiner php.ini stehen (und das wird von phpinfo()
> >> > bestätigt), aber *trotzdem* verlangt der Webserver teilweise
> >> > einen Schubs, bis er einen geänderten Link an die Applikation
> >> > weiterreicht.
> >
> >> Dann hat wohl der Server noch einen Handle offen. Denn mehr als
> >> "realpath_cache_size = 0" kann man nicht machen, um den Cache
> >> funktionslos zu machen.
> >
> > Ja, das hätte ich auch vermutet. Allerdings habe ich die obigen
> > Einstellungen über die Weihnachtsfeiertage vorgenommen und den
> > Apache seither aus anderen Gründen sicherlich ein Dutzend Mal
> > neu gestartet. Dennoch hat mich das gerade vor diesem Posting
> > wieder gebissen, und im Unterschied zu den letzten paar Wochen
> > habe ich es mir diesmal mit phpinfo() und zahlreichen
> > hin/her-Switches genauer angesehen.

> Bist du sicher, dass es der realpath_cache ist? Was ist mit Opcache?

Ja, sieht so aus. Das Problem bei diesen Dingen ist immer die
Reproduzierbarkeit, aber nach ein paar Dutzend und über Wochen
verteilten Symlinkänderungen mit/ohne OpCache scheint klar zu sein,
dass der ebenfalls seine Finger mit im Spiel hat.

Das Netz ist voll von Problemberichten, und das seit 4-5 Jahren (war
mir nur egal, weil ich bis Weihnachten noch mit PHP 7.0 arbeiten
musste). Dass das niemanden interessiert, ist auch seltsam (man
könnte auch mit der Berücksichtigung von Symlinks noch eine ganze
Menge Cachen, aber offenbar nicht mit den zur Zeit angebotenen
Konfigurationsmöglichkeiten).

Den OpCache *auch* noch komplett abzudrehen ist dann halt schon ein
bisschen viel...

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Der grüne Konsument verdient Stefan. Und Sie?
(Sloganizer)
Reply all
Reply to author
Forward
0 new messages