> Das macht FastCGI sogar für shared Hosting tauglich! Naja. Ich weiß ja nicht wieviel Arbeitsspeicher ein Server bräuchte, der Daten und Skripte von um die 3000 Kunden **im Arbeitsspeicher** bereit halten sollte. [Perl::CGI::Fast nutzt FCGI](https://perldoc.perl.org/5.8.9/CGI/Fast.html) und in der [Apache-Dok zu mod_fcgi](https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html) steht: > However, the programs invoked by mod_fcgid continue to consume resources, so the administrator must weigh the impact of invoking a particular program once per request against the resources required to leave a sufficient number of instances running continuously. Mich wundert nicht, dass dann allerhand Einstellungen folgen, die eben den Sinn haben diese Prozesse zu begrenzen und zu beenden. Das war es dann - gerade im shared-Hosting für die Massen - mit "caching". Und nicht zuletzt: Wenn der steuernde Apache den Kind-Prozess (also einen "Worker") cancelt, dann dürfte auch > So könnten in mod_php bereits beim Serverstart sämtliche Templates in den Hauptspeicher geladen werden was eine Klasse Templates tun könnte wenn sie beim Serverstart kompiliert wird. Bei Serverstart des Apache mit mod_php wird jedenfalls kein PHP-Skript kompiliert. Das gänge womöglich mit etwas wie: ~~~ php -S localhost:8000 /var/www/local/uptime.php ~~~ Allerdings wird im Shared Hosting aus gutem Grund (3000 Kunden könnten locker die maximale Zahl von 64536 Ports crashen) diese Möglichkeit ausgeschlossen. Z.B. in dem PHP so kompiliert wird, dass die Option '-S' nichts tut.

> Das macht FastCGI sogar für shared Hosting tauglich! Naja. Ich weiß ja nicht wieviel Arbeitsspeicher ein Server bräuchte, der Daten und Skripte von um die 3000 Kunden **im Arbeitsspeicher** bereit halten sollte. [Perl::CGI::Fast nutzt FCGI](https://perldoc.perl.org/5.8.9/CGI/Fast.html) und in der [Apache-Dok zu mod_fcgi](https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html) steht: > However, the programs invoked by mod_fcgid continue to consume resources, so the administrator must weigh the impact of invoking a particular program once per request against the resources required to leave a sufficient number of instances running continuously. Mich wundert nicht, dass dann allerhand Einstellungen folgen, die eben den Sinn haben diese Prozesse zu begrenzen und zu beenden. Das war es dann - gerade im shared-Hosting für die Massen - mit "caching". > So könnten in mod_php bereits beim Serverstart sämtliche Templates in den Hauptspeicher geladen werden was eine Klasse Templates tun könnte wenn sie beim Serverstart kompiliert wird. Bei Serverstart des Apache mit mod_php wird jedenfalls kein PHP-Skript kompiliert. Das gänge womöglich mit etwas wie: ~~~ php -S localhost:8000 /var/www/local/uptime.php ~~~ Allerdings wird im Shared Hosting aus gutem Grund (3000 Kunden könnten locker die maximale Zahl von 64536 Ports crashen) diese Möglichkeit ausgeschlossen. Z.B. in dem PHP so kompiliert wird, dass die Option '-S' nichts tut.

> Das macht FastCGI sogar für shared Hosting tauglich! Naja. Ich weiß ja nicht wieviel Arbeitsspeicher ein Server bräuchte, der Daten und Skripte von um die 3000 Kunden **im Arbeitsspeicher** bereit halten sollte. [Perl::CGI::Fast nutzt FCGI](https://perldoc.perl.org/5.8.9/CGI/Fast.html) und in der Apache-Dok steht: > However, the programs invoked by mod_fcgid continue to consume resources, so the administrator must weigh the impact of invoking a particular program once per request against the resources required to leave a sufficient number of instances running continuously. Mich wundert nicht, dass dann allerhand Einstellungen folgen, die eben den Sinn haben diese Prozesse zu begrenzen und zu beenden. Das war es dann - gerade im shared-Hosting für die Massen mit caching. > So könnten in mod_php bereits beim Serverstart sämtliche Templates in den Hauptspeicher geladen werden was eine Klasse Templates tun könnte wenn sie beim Serverstart kompiliert wird. Bei Serverstart des Apache mit mod_php wird jedenfalls kein PHP-Skript kompiliert. Das gänge womöglich mit etwas wie: ~~~ php -S localhost:8000 /var/www/local/uptime.php ~~~ Allerdings wird im Shared Hosting aus gutem Grund (3000 Kunden könnten locker die maximale Zahl von 64536 Ports crashen) diese Möglichkeit ausgeschlossen. Z.B. in dem PHP so kompiliert wird, dass die Option '-S' nichts tut.

> Das macht FastCGI sogar für shared Hosting tauglich! Naja. Ich weiß ja nicht wieviel Arbeitsspeicher ein Server bräuchte, der Daten und Skripte von um die 3000 Kunden **im Arbeitsspeicher** bereit halten sollte. FastCGI nutzt FCGI und in der Apache-Dok steht: > However, the programs invoked by mod_fcgid continue to consume resources, so the administrator must weigh the impact of invoking a particular program once per request against the resources required to leave a sufficient number of instances running continuously. Mich wundert nicht, dass dann allerhand Einstellungen folgen, die eben den Sinn haben diese Prozesse zu begrenzen und zu beenden. Das war es dann - gerade im shared-Hosting für die Massen mit caching. > So könnten in mod_php bereits beim Serverstart sämtliche Templates in den Hauptspeicher geladen werden was eine Klasse Templates tun könnte wenn sie beim Serverstart kompiliert wird. Bei Serverstart des Apache mit mod_php wird jedenfalls kein PHP-Skript kompiliert. Das gänge womöglich mit etwas wie: ~~~ php -S localhost:8000 /var/www/local/uptime.php ~~~ Allerdings wird im Shared Hosting aus gutem Grund (3000 Kunden könnten locker die maximale Zahl von 64536 Ports crashen) diese Möglichkeit ausgeschlossen. Z.B. in dem PHP so kompiliert wird, dass die Option '-S' nichts tut.