In IP-Symcon kann per php.ini [max_execution_time=30] die max. Laufzeit von Scripts verändert werden. Damit kann man sich „unerwünschte“ Fehlermeldungen von IPS vom Leibe halten, wenn mal wieder ein Script elendig lange (nämlich mindestens >30 Sekunden) aktiv war. Allerdings gilt diese Einstellung in der php.ini dann generell für alle Scripte im System. Spontan mag man sich denken: ist doch gut, mehr Luft nach oben.

 

Aber die Sache hat auch (mindestens) einen Haken:

Die Anzahl der max. parallel ausgeführten PHP-Threads ist auf 10 begrenzt und kann auf max. 40 erhöht werden. Damit dürfte schnell klar werden: wenn ich mehrere 100 Scripte im System habe, die alle mehr oder weniger oft ausgeführt werden wollen, kann das schon mal eng werden. Daher sollte man bestrebt sein, ein Script so effizient wie möglich arbeiten zu lassen, so dass es sich schnell wieder schlafen legen kann. Bei  mir laufen die ganz schnellen Scripte in deutlich unter 20ms ab, ich schätze, im Durchschnitt werden es 100-200ms sein. Während dieser Laufzeit ist eben ein PHP-Thread pro Script reserviert. Wollen 10 Scripte gleichzeitig laufen, wird es eng (denn das Webfront braucht ja auch noch Ressourcen), mehr als 10 gleichzeitig geht schlichtweg nicht (immer bezogen auf die Default-Einstellungen von IPS!). 

Alles, was über 10 gleichzeitig laufen soll, wandert in die Script-Queue und wird nachgeschoben, wenn ein PHP-Thread frei wird. Spätestens jetzt sollte klar werden, dass man hier mit jeder Millisekunde Laufzeit geizen sollte (ok ok, ist sicher etwas übertrieben).

Und mit der Standardeinstellung von 30 Sekunden fallen eben die Schnarchtassen unter den Scripts schnell auf: sie bekommen ein rotes Ausrufezeichen: „Du bist ganz böse!“

Allein das führt schon dazu, dass man automatisch beginnt, hier nach Ursachen zu forschen und diese abzustellen. Setzt man nun die max_execution_time hoch, werden diese „Schnarchtassen-Scripte“ weniger oder gar nicht auffallen. Man wird über lange Zeit nicht merken, dass man eigentlich schlechten Code  zusammengehäkelt hat. Mir persönlich ist es deutlich lieber, wenn die schwarzen Schafe gleich auffällig werden  – und ich die Ursachen abstellen kann.

 

Der Umkehrschluss

Wenn man das Thema umgekehrt betrachtet, wird es ebenso unangenehm: Ich hatte mal für ein paar Tage die max_execution_time auf 5 Minuten gestellt (bewusst, ich war mir der Risiken vollkommen bewusst). Parallel hab ich in einem anderen Projekt entwickelt und mir ganz schnell in den A**** Hintern gebissen, weil ich jedesmal 5 Minuten warten musste, bis das System das betroffene, fehlerhafte Script als „fehlerhaft“ eingestuft und beendet hat.

 

Fazit

seit dem habe ich mir angewöhnt, wenn überhaupt notwendig – die max_execution_time in jedem Script individuell zu setzen. Im Moment sind das geschätzt 5% aller Scripte im System. Die IPS-Systemeinstellung (in der php.ini) bleibt auf 30 Sekunden.

Damit fahre ich jetzt seit über einem halben Jahr, und es läuft deutlich besser.

 

Was für individuelle Scriptlaufzeit-Definition spricht (Zusammenfassung)

  • globale Einstellungen in der php.ini gelten für alle Scripte, egal ob benötigt oder nicht
  • durch globale Standartwerte werden problematische Scripte schneller erkannt, schleichende System-Flaschenhälse können vermieden werden
  • durch individuelle Definition der Scriptlaufzeiten lassen sich problematische Scripte optimal einstellen
  • kurze Default-Laufzeiten wirken disziplinierend auf den Entwickler

 

Katze aus dem Sack: wie?

ach, fast vergessen: das „Wie“ hatte ich noch nicht erwähnt. Also: es gibt mehrere Möglichkeiten, die Scriptlaufzeit individuell zu verändern. Ich nutze hauptsächlich den PHP-Befehl  max_execution_time. Die max. Laufzeit stelle ich fast immer auf typische Scriptlaufzeit in meinem System (Script mehrmals laufen lassen und Ausführungsdauer messen) * 2. 

 

Beispiel:

 

 

Und die Praxis:

Wennäh (wgreipl) macht es genau umgekehrt: die Globale Einstellung ist bei ihm bei 240 Sekunden, die „kritischen Scripte“ hatter individuell auf 180 Sekunden begrenzt …muaaahhhh 

 


Getagged mit
 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

css.php