Hi!
garvinhicking wrote:
Eine "Ping-Schleife" gibt es nicht - beim Eintrag selbst pingen wird das nur
Ok - an diese These hatte ich ja entsprechende "Fragezeichen" drangemacht.
garvinhicking wrote:
Ich betreue ua. eine Anwendung, die viele Zugriffe verdauen muß, und die für bestimmte Zwecke relativ regelmäßig in der Größenordnung von einer Stunde CPU-Zeit braucht, was von vorneherein bekannt war und ok ist. Also steht die entsprechende Anweisung auf gut einer Stunde... was eine Katastrophe wäre, wenn irgendein "normaler" Zugriff so eine Belastung auslösen könnte. Siehe auch den Abschnitt über die Auswirkungen von "irgendwo" abgebrochenen Prozessen weiter unten.
Dafür sollte definitiv ein eigener, gekappselter VHost eingerichtet werden.
Ist es...
garvinhicking wrote:
aber falsch ist nach meinem Eindruck, daß er in der Anwendung nicht darauf reagieren kann.
Da lasse ich mich gerne eines besseren Belehren, was schlägst Du vor wie mit PHP Netzwerkproblemem umgegangen werden soll? Wenn die PHP Timeouts nicht korrekt konfiguriert sind und endlos laufen dürfen,
Tja... ich kenne keine Netzwerk-Timeouts in der php.ini (dazu gibt die Suche auf php.net auch nichts aus), nur ein Timeout für die Laufzeit des Gesamtprozesses, aber ich kenne Timeouts als Parameter für Netzwerkfunktionen in PHP selbst, so daß man als Anwendungsentwickler in der Lage sein sollte, diese zu setzen. Wenn das in PHP nicht funktionieren sollte, obwohl die Beschreibung bei diesen Funktionen: stream_select(), stream_set_timeout(), fsockopen() etc.pp. so beschrieben ist, und wenn die Signale, mit denen man solche Operationen abbrechen können müßte, auch nicht funktionieren, dann weiß ich nicht wirklich, wie man das Problem lösen kann. Die Beschreibung der Funktionen auf php.net liest sich so, als würden da nur libc-Aufrufe an PHP durchgereicht, und dann
müßte es funktionieren. Allerdings bin ich selber schon mehr als einmal auf Fehler in PHP selbst gestoßen, die teilweise nur auf manchen Plattformen auftraten, von daher ist das nur meine Vermutung, der Du Deine Erfahrung entgegensetzen kannst.
garvinhicking wrote:
Die PHP Timeouts liegen eine Schicht "höher", d.h. bei grundlegenden Firewall-Problemen kommt PHP garnicht dazu seine Timeouts festuzlegen.
Diesen Abschnitt verstehe ich nicht. Meinst Du, daß etwaige (lange) DNS-Timeouts nicht von den Timeouts beeinflußt werden können, die Du in den og. Funktionen angibst? Oder sind die Timeouts schlimmstenfalls durch aktives Warten implementiert (was die 100% CPU-Last erklären könnte)?
garvinhicking wrote:
Das hängt alles vom Setup ab, und cummins' provder hat da einfach Mist gebaut, denn 100% CPU Last DARF NICHT SEIN bei einem einzelnen PHP-Prozess der nichts anderes tut als auf einen timeout zu warten.
In diesem Punkt sind wir einer Meinung: Ein PHP-Prozeß, der auf ein Timeout wartet, darf keine CPU-Zeit verbraten, zumindest dann nicht, wenn die fraglichen Funktionen mit passivem Warten implementiert sind.
Wir diskutieren an dieser Stelle nur über die Frage, wie das Setup dazu führen soll, daß ein wartender Prozeß
doch (viel) CPU-Zeit frißt. Das verstehe ich nicht. Hast Du dazu vielleicht eine Theorie?
Meine Theorie ist, daß ein Prozeß, der CPU-Zeit frißt, irgendetwas tut, also
nicht einfach nur (passiv) wartet. Wenn man das nicht durch Anschauen des Anwendungscodes (= s9y) sieht - Deine These ist, daß der Code in dieser Hinsicht fehlerfrei ist, und daß deshalb da nichts sein kann - hätte man den PHP-Prozeß eigentlich mit einem Debugger tracen müssen, aber das ist natürlich ziemlicher Aufwand. Wenn ich die Site von dem Menschen mit dem Problem hätte, würde ich gerne mal versuchen, das Problem lokal nachzuvollziehen. Ob sich dann herausstellt, daß es ein Anwendungsfehler oder ein PHP-Problem ist, kann man jetzt ja (meiner Meinung nach) gar nicht sagen, und dementsprechend wären ja auch die Lösungsansätze verschieden.
garvinhicking wrote:
Außerdem kann man, wenn man wirklich viele Rechte auf dem System hat, vor bestimmten Operationen die Maximallaufzeit des Prozesses selbst heruntersetzen ( set_time_limit() ). Von daher meine ich nicht, daß man als Systemadministrator Begrenzungen für Serendipity setzen müssen sollte.
Derartige timelimits sind Teil eines sinnvollen Serversetups, eine PHP-Anwendung sollte dies meiner Meinung nach nicht überschreiben.
Wenn man weiß, daß in einem bestimmten Codepfad keine aufwendige Aktion passieren kann, man aber an anderen Stellen
viel mehr CPU-Zeit braucht, könnte man in den "billigen" Code-Pfaden die Begrenzung heruntersetzen. So war das von mir aus jedenfalls gemeint.
garvinhicking wrote:
Klassisches Beispiel von "doof gedacht": Das CMS Redaxxo setzt beim DAtenbankdump ein Timelimit von 600 sekunden. Wir haben aber ein so großes System, dass der Dump rund 900 Sekunden dauert. Also müssen wir tatsächlich den Code von redaxo patchen um die Skriptlaufzeit zu beeinflussen, obwohl es sonst definitiv eine Aufgabe der .htaceess und php.ini wäre.
Was ich meinte, ist, daß man z.B. in der S9Y-Konfiguration einstellen könnte, wieviel Zeit man denn dem Prozeß oder z.B. den Netzwerkfunktionen geben möchte. Sozusagen als zusätzlicher Sicherheitsgurt, falls das Gastssystem unpassend konfiguriert ist. Ich habe keine Ahnung davon, was für S9Y angemessen wäre - reichen die 30 Sekunden CPU-Limit, die in einer "Standard-php.ini" eingestellt sind?
garvinhicking wrote:
Sorry dass ich hier etwas aufgebracht bin, abe3r ich finde die Diskussion etwas müßig weil ein derartiges Setup in der realen PHP-Welt totaler Schwachfug ist.
Viele Grüße,
Garvin
Hier habe ich den Eindruck, daß wir aneinander vorbeireden.
Du hast eben von Deiner Redaxo-Geschichte mit einem Timeout von einer Viertelstunde geredet. Ich bin mir sicher, daß dem Menschen, der das Problem geschildert hat, bzw. seinem Hoster, kaum damit geholfen gewesen wäre, das Timeout auf eine Viertelstunde einzustellen, obwohl das ein Wert aus der (Deiner) "realen PHP-Welt" ist. Und wie gesagt, er hat ja auch noch andere Anwendungen, die viel mehr CPU-Zeit als die 30 Sekunden zu brauchen scheinen, und deren Lauffähigkeit dagegen sprach, das Timeout generell stark herunterzusetzen. Davon abgesehen wäre S9Y bei dieser problematischen Seite ja bei 30 Sekunden abgestürzt bzw. abgebrochen worden, nur hätte es nicht mehr den ganzen Server in die Tiefe gezogen. Mit anderen Worten: Eine kleine Zeitbegrenzung einzustellen, ist keine Lösung, sondern nur ein Würgaround.
Mir fehlt schlicht ein Ansatz, wie ich speziell dieses Problem im Voraus ausschließen kann, ohne auf S9Y verzichen zu müssen. Auf die ganzen anderen Probleme, was beim Abbruch der Anwendung passiert, bist Du ja leider gar nicht eingegangen, aber der Normalfall (nicht nur) bei PHP-Anwendungen ist definitiv
nicht, daß die Anwendungen vom System aus abgebrochen werden, sondern, daß dieses Timeout (max_execution_time etc.) nur als letzter Sicherheitsgurt des Systems gegen Programmierfehler oder Fehler in PHP gedacht sind, notfalls eben zu Lasten der abgebrochenen Anwendung. Und das ist völlig unabhängig davon, auf welchen Wert dieses Timeout letzten Endes eingestellt ist, solange es genügend hoch ist und die Anwendung im Normalfall (= solange kein Fehler auftritt) "ordentlich" terminiert. Das Timeout hilft nur gegen eine unabsichtliche Serverüberlastung, aber z.B. nicht dagegen, daß die Seite falsch oder nicht angezeigt wird (was beim Abbruch des Prozesses zu erwarten ist), oder dagegen, daß eine Datenbanktransaktion, die aus mehreren Abfragen besteht, nicht abgeschlossen werden kann.
Das Problem
muß meiner Ansicht nach noch irgendwo anders als in einer zu hohen Zeitbegrenzung in der php.ini liegen, und ich sähe dieses Problem - durchaus unter Einsatz eigener Arbeitszeit - gerne gelöst, bevor ich mich entschließe, S9Y-Hosting anzubieten.
Wenn ich mir vorstelle, daß ein Benutzer durch eine einfache Aktion versehentlich einen Server plätten kann (= Ist-Zustand), ohne daß ich von diesem Benutzer den Preis für einen Server bekomme, dann habe ich da ein Problem, und ich habe ebenfalls ein Problem, wenn der Benutzer dauernd auf der Matte steht, weil seine Anwendung nicht richtig läuft, sondern stattdessen dauernd vom System abgebrochen wird.
Viele Grüße,
Toni
