> FPN, PHP 7.0, NGINX, Linux > Das Skript wird per AJAX im Browser alle 5 Sekungen aufgerufen. Ganz einfach. Auch der NGINX kann nur eine bestimmte Anzahl an Prozessen (="laufenden Abrufe", Threads) verwalten. Wenn aller 5 Sekunden ein Skript aufgerufen wird, dass aber 10 Sekunden läuft, dann sieht das wie folgt aus: Sekunden | Prozesse gestartet | Prozesse beendet | laufende Prozesse 0.1 |1|0|1 5.1 |2|0|2 10.1 |3|1|2 15.1 |4|1|3 20.1 |5|2|3 25.1 |6|2|4 Ergo erhöht sich die Anzahl der laufenden Prozesse stetig aller 10 Sekunden um einen und irgendwann will bzw. darf bzw. kann der NGINX nicht mehr, weil der einfach keinen weiteren Kindprozess mehr erstellen will bzw. darf bzw. kann, welcher die Anfrage entgegen nimmt. Im Error-Log steht nichts, weil der Webserver von den Verbindungsversuchen nicht mal was erfährt. Die "sterben" schon auf TCP-Ebene (OSI-Schicht 3). Allerdings hätte ein Blick in die Entwicklerkonsole des Browsers durchaus Klarheit verschaffen können. **Ein anderer Webserver (Apache oder welcher auch immer) löst das Problem nicht, weil es bei den Voraussetzungen bleibt.** Verstärken könnte den Effekt, dass mit der Anzahl der Threads oder Prozesse diese auch noch mehr Zeit für die Abarbeitung benötigen, weil der Prozessor diesen auch nur begrenzt "Zeitscheiben" zur Verfügung stellt. Also steigt ab dem Zeitpunkt, wo keine freien Prozessor-Threads zur Verfügung stehen, die Anzahl der Prozesse noch schneller an. Das kann und wird wohl noch dramatischer sein, wenn die Prozesse womöglich auf die Freigabe von Ressourcen, wie z.B. exklusiv gesperrten Dateien warten. **Einzige Lösung:** Die Dauer der Bearbeitung eines Abrufes (bisher 10 Sekunden) **muss** unter der des Intervalls (hier 5 Sekunden) liegen. Etwas wie `htop` oder ein wiederholtes `ps ax | grep ngingx` (ggf. mit Root-rechten in einem Terminal auf dem Server) dürfte Dir den Beweis liefern.

> FPN, PHP 7.0, NGINX, Linux > Das Skript wird per AJAX im Browser alle 5 Sekungen aufgerufen. Ganz einfach. Auch der NGINX kann nur eine bestimmte Anzahl an Prozessen (="laufenden Abrufe", Threads) verwalten. Wenn aller 5 Sekunden ein Skript aufgerufen wird, dass aber 10 Sekunden läuft, dann sieht das wie folgt aus: Sekunden | Prozesse gestartet | Prozesse beendet | laufende Prozesse 0.1 |1|0|1 5.1 |2|0|2 10.1 |3|1|2 15.1 |4|1|3 20.1 |5|2|3 25.1 |6|2|4 Ergo erhöht sich die Anzahl der laufenden Prozesse stetig aller 10 Sekunden um einen und irgendwann will bzw. darf bzw. kann der NGINX nicht mehr, weil der einfach keinen weiteren Kindprozess mehr erstellen will bzw. darf bzw. kann, welcher die Anfrage entgegen nimmt. Im Error-Log steht nichts, weil der Webserver von den Verbindungsversuchen nicht mal was erfährt. Die "sterben" schon auf TCP-Ebene (OSI-Schicht 3). Allerdings hätte ein Blick in die Entwicklerkonsole des Browsers durchaus Klarheit verschaffen können. **Ein anderer Webserver (Apache oder welcher auch immer) löst das Problem nicht, weil es bei den Voraussetzungen bleibt.** Verstärken könnte den Effekt, dass mit der Anzahl der Threads oder Prozesse diese auch noch mehr Zeit für die Abarbeitung benötigen, weil der Prozessor diesen auch nur begrenzt "Zeitscheiben" zur Verfügung stellt. Also steigt ab dem Zeitpunkt, wo keine freien Prozessor-Threads zur Verfügung stehen, die Anzahl der Prozesse noch schneller an. Das kann und wird wohl noch dramatischer sein, wenn die Prozesse womöglich auf die Freigabe von Ressourcen, wie z.B. exklusiv gesperrten Dateien warten. **Einzige Lösung:** Die Dauer der Bearbeitung eines Abrufes (bisher 10 Sekunden) **muss** unter der des Intervalls (hier 10 Sekunden) liegen. Etwas wie `htop` oder ein wiederholtes `ps ax | grep ngingx` (ggf. mit Root-rechten in einem Terminal auf dem Server) dürfte Dir den Beweis liefern.

> FPN, PHP 7.0, NGINX, Linux > Das Skript wird per AJAX im Browser alle 5 Sekungen aufgerufen. Ganz einfach. Auch der NGINX kann nur eine bestimmte Anzahl an Prozessen (="laufenden Abrufe", Threads) verwalten. Wenn aller 5 Sekunden ein Skript aufgerufen wird, dass aber 10 Sekunden läuft, dann sieht das wie folgt aus: Sekunden | Prozesse gestartet | Prozesse beendet | laufende Prozesse 0.1 |1|0|1 5.1 |2|0|2 10.1 |3|1|2 15.1 |4|1|3 20.1 |5|2|3 25.1 |6|2|4 Ergo erhöht sich die Anzahl der laufenden Prozesse stetig aller 10 Sekunden um einen und irgendwann will bzw. darf bzw. kann der NGINX nicht mehr, weil der einfach keinen weiteren Kindprozess mehr erstellen will bzw. darf bzw. kann, welcher die Anfrage entgegen nimmt. Im Error-Log steht nichts, weil der Webserver von den Verbindungsversuchen nicht mal was erfährt. Die "sterben" schon auf TCP-Ebene (OSI-Schicht 3). Allerdings hätte ein Blick in die Entwicklerkonsole des Browsers durchaus Klarheit verschaffen können. **Ein anderer Webserver (Apache oder welcher auch immer) löst das Problem nicht, weil es bei den Voraussetzungen bleibt.** Verstärken könnte den Effekt, dass mit der Anzahl der Threads oder Prozesse diese auch noch mehr Zeit für die Abarbeitung benötigen, weil der Prozessor diesen auch nur begrenzt "Zeitscheiben" zur Verfügung stellt. Also steigt ab dem Zeitpunkt, wo weniger freie Prozessor-Threads zur Verfügung stehen, die Anzahl der Prozesse noch schneller an. Das kann und wird wohl noch dramatischer sein, wenn die Prozesse womöglich auf die Freigabe von Ressourcen, wie z.B. exklusiv gesperrten Dateien warten. **Einzige Lösung:** Die Dauer der Bearbeitung eines Abrufes (bisher 10 Sekunden) **muss** unter der des Intervalls (hier 10 Sekunden) liegen. Etwas wie `htop` oder ein wiederholtes `ps ax | grep ngingx` (ggf. mit Root-rechten in einem Terminal auf dem Server) dürfte Dir den Beweis liefern.

> FPN, PHP 7.0, NGINX, Linux > Das Skript wird per AJAX im Browser alle 5 Sekungen aufgerufen. Ganz einfach. Auch der NGINX kann nur eine bestimmte Anzahl an Prozessen (="laufenden Abrufe", Threads) verwalten. Wenn aller 5 Sekunden ein Skript aufgerufen wird, dass aber 10 Sekunden läuft, dann sieht das wie folgt aus: Sekunden | Prozesse gestartet | Prozesse beendet | laufende Prozesse 0.1 |1|0|1 5.1 |2|0|2 10.1 |3|1|2 15.1 |4|1|3 20.1 |5|2|3 25.1 |6|2|4 Ergo erhöht sich die Anzahl der laufenden Prozesse stetig aller 10 Sekunden um einen und irgendwann will bzw. darf bzw. kann der NGINX nicht mehr, weil der einfach keinen weiteren Kindprozess mehr erstellen will bzw. darf bzw. kann, welcher die Anfrage entgegen nimmt. Ein anderer Webserver (Apache oder welcher auch immer) löst das Problem nicht, weil es bei den Voraussetzungen bleibt. Verstärken könnte den Effekt, dass mit der Anzahl der Threads oder Prozesse diese auch noch mehr Zeit für die Abarbeitung benötigen, weil der Prozessor diesen auch nur begrenzt "Zeitscheiben" zur Verfügung stellt. Also steigt ab dem Zeitpunkt, wo weniger freie Prozessor-Threads zur Verfügung stehen, die Anzahl der Prozesse noch schneller an. Das kann und wird wohl noch dramatischer sein, wenn die Prozesse womöglich auf die Freigabe von Ressourcen, wie z.B. exklusiv gesperrten Dateien warten. **Einzige Lösung:** Die Dauer der Bearbeitung eines Abrufes (bisher 10 Sekunden) **muss** unter der des Intervalls (hier 10 Sekunden) liegen. Etwas wie `htop` oder ein wiederholtes `ps ax | grep ngingx` (ggf. mit Root-rechten in einem Terminal auf dem Server) dürfte Dir den Beweis liefern.

> FPN, PHP 7.0, NGINX, Linux > Das Skript wird per AJAX im Browser alle 5 Sekungen aufgerufen. Ganz einfach. Auch der NGINX kann nur eine bestimmte Anzahl an Prozessen (="laufenden Abrufe", Threads) verwalten. Wenn aller 5 Sekunden ein Skript aufgerufen wird, dass aber 10 Sekunden läuft, dann sieht das wie folgt aus: Sekunden | Prozesse gestartet | Prozesse beendet | laufende Prozesse 0.1 |1|0|1 5.1 |2|0|2 10.1 |3|1|2 15.1 |4|1|3 20.1 |5|2|3 25.1 |6|2|4 Ergo erhöht sich die Anzahl der laufenden Prozesse stetig aller 10 Sekunden um einen und irgendwann will bzw. darf bzw. kann der NGINX nicht mehr, weil der einfach keinen weiteren Kindprozess mehr erstellen will bzw. darf bzw. kann, welcher die Anfrage entgegen nimmt. Ein anderer Webserver (Apache oder welcher auch immer) löst das Problem nicht, weil es bei den Voraussetzungen bleibt. **Einzige Lösung:** Die Dauer der Bearbeitung eines Abrufes (bisher 10 Sekunden) **muss** unter der des Intervalls (hier 10 Sekunden) liegen. Etwas wie `htop` oder ein wiederholtes `ps ax | grep ngingx` (ggf. mit Root-rechten in einem Terminal auf dem Server) dürfte Dir den Beweis liefern.

> FPN, PHP 7.0, NGINX, Linux > Das Skript wird per AJAX im Browser alle 5 Sekungen aufgerufen. Ganz einfach. Auch der NGINX kann nur eine bestimmte Anzahl an Prozessen (="laufenden Abrufe", Threads) verwalten. Wenn aller 5 Sekunden ein Skript aufgerufen wird, dass aber 10 Sekunden läuft, dann sieht das wie folgt aus: Sekunden | Prozesse gestartet | Prozesse beendet | laufende Prozesse 0.1 |1|0|1 5.1 |2|0|2 10.1 |3|1|2 15.1 |4|1|3 20.1 |5|2|3 25.1 |6|2|4 Ergo erhöht sich die Anzahl der laufenden Prozesse stetig aller 10 Sekunden um einen und irgendwann will der NGINX nicht mehr. Ein anderer Webserver löst das Problem nicht. Einzige Lösung: Die Dauer der Bearbeitung eines Abrufes (bisher 10 Sekunden) **muss** unter der des Intervalls (hier 10 Sekunden) liegen. Etwas wie `htop` oder ein wiederholtes `ps ax | grep ngingx` (ggf. mit Root-rechten in einem Terminal auf dem Server) dürfte Dir den Beweis liefern.

-> FPN, PHP 7.0, NGINX, Linux -> Das Skript wird per AJAX im Browser alle 5 Sekungen aufgerufen. Ganz einfach. Auch der NGINX kann nur eine bestimmte Anzahl an Prozessen (="laufenden Abrufe", Threads) verwalten. Wenn aller 5 Sekunden ein Skript aufgerufen wird, dass aber 10 Sekunden läuft, dann sieht das wie folgt aus: Sekunden | Prozesse gestartet | Prozesse beendet | laufende Prozesse 0.1 |1|0|1 5.1 |2|0|2 10.1 |3|1|2 15.1 |4|1|3 20.1 |5|2|3 25.1 |6|2|4 Ergo erhöht sich die Anzahl der laufenden Prozesse stetig aller 10 Sekunden um einen und irgendwann will der NGINX nicht mehr. Ein anderer Webserver löst das Problem nicht. Einzige Lösung: Die Dauer der Bearbeitung eines Abrufes (bisher 10 Sekunden) **muss** unter der des Intervalls (hier 10 Sekunden) liegen. Etwas wie `htop` oder ein wiederholtes `ps ax | grep ngingx` (ggf. mit Root-rechten in einem Terminal auf dem Server) dürfte Dir den Beweis liefern.

-> FPN, PHP 7.0, NGINX, Linux -> Das Skript wird per AJAX im Browser alle 5 Sekungen aufgerufen. Ganz einfach. Auch der NGINX kann nur eine bestimmte Anzahl an Prozessen (="laufenden Abrufe", Threads) verwalten. Wenn aller 5 Sekunden ein Skript aufgerufen wird, dass aber 10 Sekunden läuft, dann sieht das wie folgt aus: Sekunden | Prozesse gestartet | Prozesse beendet | laufende Prozesse 0.1 |1|0|1 5.1 |2|0|2 10.1 |3|1|2 15.1 |4|1|3 20.1 |5|2|3 25.1 |6|2|4 Ergo erhöht sich die Anzahl der laufenden Prozesse stetig aller 15 Sekunden um einen und irgendwann will der NGINX nicht mehr. Ein anderer Webserver löst das Problem nicht. Einzige Lösung: Die Dauer der Bearbeitung eines Abrufes (bisher 10 Sekunden) **muss** unter der des Intervalls (hier 10 Sekunden) liegen. Etwas wie `htop` oder ein wiederholtes `ps ax | grep ngingx` (ggf. mit Root-rechten in einem Terminal auf dem Server) dürfte Dir den Beweis liefern.