Angenommen, Sie haben einen Daemon geschrieben, der eine Jobwarteschlange bedient. Verschiedene andere Software schreibt Jobs für den Daemon in die Warteschlange. Der Daemon fragt die Warteschlange alle paar Sekunden nach ausstehenden Jobs ab. Angenommen, die Warteschlange ist als Tabelle in einer MySQL-Datenbank implementiert und der Daemon ist eine einfache Schleife:
Der Daemon muss den unterbrochenen Dienst vom MySQL DB-Server und die Unterbrechung von DB-Verbindungen überleben.
Würden Sie den Daemon so konfigurieren, dass er sich einmal pro Zyklus mit dem DB-Server verbindet? d. h. Verbindung vor 1. und Trennung zwischen 2 und 3?
Oder hättest du daemon eine Verbindung offen lassen? In diesem Fall muss es auch a) erkennen, wenn der Server oder die Verbindung nicht funktioniert, b) die Verbindung trennen und wiederherstellen und c) ohne dabei DB-Verbindungen, Verbindungsbeschreibungsdeskriptoren oder andere tote Ressourcen zu akkumulieren.
Wenn Sie eine Präferenz haben, warum?
Vor-und Nachteile?
Faktoren, die in das Design einfließen?
Irgendwelche anderen Ansätze?
Die Antwort hier: mysql Verbindung von Daemon in PHP geschrieben nicht sagen, warum es besser ist, die Verbindung offen zu halten. Ich habe an anderer Stelle gelesen, dass der Aufwand pro Verbindung in MySQL sehr gering ist. Es ist also nicht offensichtlich, warum es immer besser ist, eine Serververbindung zu nutzen, als alle paar Sekunden zu verbinden / trennen.
In meinem Fall ist der Daemon in PHP geschrieben.
Ich arbeite tatsächlich an etwas , das sehr nah an dem ist, was du beschrieben hast, aber in meinem Falls der Daemon nicht nach Event fragt, werden sie asynchron über XMPP abgerufen (aber das ist neben dem Punkt).
Schneide den Mittleren Mann aus
Ich denke, anstatt die Ereignisse in der Datenbank zu speichern und sie mit MySQL abzurufen, könntest du wahrscheinlich Gearman verwenden, um sie asynchron vom Client zu senden ( Beispiel ).
Garbage Collection
PHP ist nicht wirklich dazu gedacht, als Daemon zu laufen, und es war erst PHP 5.3, als es kreisförmige Referenz-Garbage-Collection , dass es zu einer realisierbaren Option wurde. Es ist sehr wichtig, dass Sie PHP 5.3 verwenden, wenn Sie langfristig ohne Speicherverlust arbeiten möchten.
Eine andere Sache, die man bei GC beachten sollte, ist, dass Speicher nur dann frei ist, wenn er nicht mehr referenziert wird (irgendwo). Wenn Sie also dem globalen Gültigkeitsbereich eine Variable zuweisen, wird diese solange vorhanden sein, bis der Daemon beendet wird. Es ist wichtig, dass jeder Code, den Sie erstellen oder verwenden, an einigen Stellen keine Variablen aufbaut (z. B. statisches Protokoll, keine alten Daten entfernen usw.).
Statistikcache
Eine andere Sache ist, dass es wichtig ist, clearstatcache so oft auszuführen. Da Ihr PHP-Prozess nicht neu gestartet wird, ist es wichtig, diesen Aufruf manuell durchzuführen, um zu verhindern, dass alte Statistikdaten (die sich möglicherweise auf Sie auswirken) erhalten werden. Laut der Dokumentation werden diese Funktionen zwischengespeichert.
Betroffene Funktionen sind stat (), lstat (), file_exists (), is_writable (), is_readable (), is_executable (), is_file (), is_dir (), is_link (), filectime (), fileatime (), filemtime (), fileinode (), filegroup (), filowowner (), filesize (), filetype () und fileperms ().
Ressourcenverwaltung
Wenn Sie während der Laufzeit Ihres Prozesses Dinge wie MySQL verwenden, würde ich vorschlagen, beim Start eine Verbindung herzustellen und sie am Leben zu erhalten. Obwohl es auf der MySQL-Seite mehr Ram verwenden könnte, werden Sie etwas Latenz und CPU-Overhead sparen, da Sie nicht alle 1 Sekunde eine Verbindung herstellen müssen.
Keine URL-Anfrage
Dies mag offensichtlich erscheinen, aber mit CLI PHP gibt es keine URL-Anfrage-Informationen. Einige Bibliotheken sind nicht in diesem Sinne geschrieben, und dies kann einige Probleme verursachen.
LooPHP
Ich werde hier ein schamloses Plug-in für ein Framework einfügen, das ich geschrieben habe, um bei der Verwaltung von PHP-Daemons zu helfen. LooPHP ist ein Run-Loop-Framework, mit dem Sie Ereignisse planen oder Listener für abstrakte Quellen erstellen können (Socket, Stream usw.). In meinem Fall habe ich den Daemon mehr als eine Sache, also ist es sehr hilfreich, wenn das System alle Timer für mich verfolgt, damit ich stream_select für die XMPP-Verbindung effektiv abfragen kann.
Wenn Sie einen zuverlässigen Daemon erstellen möchten, müssen Sie in beiden Fällen Datenbankfehler / Verbindungsunterbrechungen auffangen und erneut verbinden (trennen oder verbunden bleiben). Da Sie dies trotzdem tun müssen, können Sie auch eine Verbindung erneut verwenden.
Mit anderen Worten, nur weil Sie eine frisch geöffnete Verbindung haben, heißt das nicht, dass die Abfrage nicht fehlschlägt und die Verbindung erneut geöffnet und erneut versucht werden muss.
Ich glaube also, der sauberste Weg wäre, die Verbindung zu erhalten. Aber nur knapp.
Ich denke, dass das Beste, was Sie tun können, ist, die Zeit zu messen, die benötigt wird, um sich mit der Datenbank zu verbinden / davon zu trennen. Dann versuchen Sie es mit einer Art Wahrscheinlichkeit, dass der Datenbankserver nicht mehr verfügbar ist. Ermitteln Sie die Kosten einer permanenten Serververbindung. Und schließlich versuchen Sie, die Kosten (in Stunden, Ärger oder was auch immer) des Hinzufügens von Code, der Probleme mit der Datenbankverbindung behandelt, zu ermitteln. Wenn Sie diese Zahlen erfolgreich ermitteln und vergleichen können, haben Sie eine Antwort. Es ist schwierig für mich (und ich nehme an, dass irgendjemand), gute Schätzungen für diese Werte zu finden, aber die Schlussfolgerung wird wahrscheinlich sein, dass es eine Wahl zwischen Leistung versus Machbarkeit (in Bezug auf niedrigere Kosten) ist.