CGI oder FastCGI mit 1GB RAM?

[Bachsau]

So, 1 GB RAM OpenVZ-Container, und ich bin gerade am überlegen, ob ich meine Scripte mit CGI oder FastCGI betreiben soll. FastCGI cachet laut Beschreibung sehr viel, und lässt die Prozesse laufen. Das Klingt nach RAM-Fresserei. Allerdings startet CGI für wirklich jeden Aufruf eine eigene Instanz.

Ausprobieren, oder gibt's schon Erfahrungswerte?

PS: Betrieb über Module kommt nicht in Frage, da ich suexec einsetzen will.

 

[Spin-Doc]

Du hast nicht geschrieben um welchen Interpreter es geht, ich nehme an php. Also nimmst du fastcgi über mod_fcgid. Ich sehe nicht wirklich einen Grund dass man sich mit standard cgi rumschlagen sollte.

 

[virtual2]

Kurz und knapp: CGI - kein FastCGI

FastCGI ist der riesen Ressourcenfresser, da dieser sich nen haufen Ressourcen reserviert.

 

[dev]

FastCGI ist der riesen Ressourcenfresser, da dieser sich nen haufen Ressourcen reserviert.

Das heisst konkret? Was ist 'nen haufen Ressourcen'?

 

[biosphere]

Hallo,

ich denke, die Frage sollte wahrscheinlich eher sein: mod_php oder FastCGI?

Der Unterschied zwischen CGI und FastCGI ist ja, dass CGI für jeden Request einen eigenen seperaten Prozess startet und nach dem "servieren" der Anfrage wieder beendet wird. Das ist natürlich mit einem großen Aufwand verbunden.

FastCGI möchte dieses Problem verhindern und arbeitet so, dass Anfangs der Interpreter geladen wird, und dann solange im Speicher verweilt und Anfragen bearbeitet, bis er beendet wird oder eine sonstige Abbruchbedingung eintritt (z.B. maximale Anzahl an Requests). Diese Methode ist um einiges schneller als herkömmliches CGI.

mod_php geht dabei einen ganz anderen Weg. mod_php ist ein Apache Modul, dass den PHP Interpreter mit in einen Apache Serverprozess lädt. Somit wird der Overhead von einer Verbindung zwischen User->Apache->PHP-Backend(FastCGI)->Apache->User auf User->Apache(hier wird bereits das PHP interpretiert)->User reduziert. Das sollte theoretisch noch ein bisschen schneller als FastCGI sein.

FastCGI bietet aber gegenüber mod_php bessere Sicherheitseinstellungen, da die FastCGI Prozesse als seperater User ausgeführt werden können.
Als Fazit kann man sagen, dass mod_php einfach bequem aufzusetzen ist, aber nur mit dem Prefork MPM funktioniert, was statische Inhalte schlechter ausliefert als das Worker MPM, welches auch mit FastCGI funktioniert.

Vom Speicherverbrauch sollte FastCGI auf lange Sicht etwas effizienter als mod_php sein, da praktischerweiße nach einer Zeit wieder Speicher freigegeben wird (oder auch nicht, wenn man das will) und bei mod_php nicht. Von Lastspitzen bzw. vom Maximalverbrauch würde ich sagen ist es egal für was man sich entscheidet.

Ich hoffe ich konnte helfen.

Grüße
Alex

 

[DerMitSkill]

Als Fazit kann man sagen, dass mod_php einfach bequem aufzusetzen ist, aber nur mit dem Prefork MPM funktioniert, was statische Inhalte schlechter ausliefert als das Worker MPM, welches auch mit FastCGI funktioniert.

Also.. ich hatte noch nie Probleme mit Worker MPM und mod_php.

 

[biosphere]

Funktioniert das mittlerweile? PHP wurde ja immer nachgesagt, nicht Threadsafe zu sein.
Aber gut, dann revidiere ich meine Aussage, dann geht mod_php auch mit Worker

Freundliche Grüße
Alex

 

[Bachsau]

Du hast nicht geschrieben um welchen Interpreter es geht, ich nehme an php.

Ja, php5. Später vielleicht auch Python.

ich denke, die Frage sollte wahrscheinlich eher sein: mod_php oder FastCGI?

Siehe oben:
> Betrieb über Module kommt nicht in Frage, da ich suexec einsetzen will.

Bei den knappen Resourcen, die so ein VPS bietet, kommt CGI durchaus in Frage, falls FCGI zuviel Speicher frisst.

 

[MTLServices]

Ausprobieren, oder gibt's schon Erfahrungswerte?

Du merkst es selbst, ausprobieren scheint wohl die einzige Option, da hier jeder etwas anderes anpreist. Eine generell perfekte Lösung gibt es diesbezüglich m.E. nicht.
Ähnlich hier: https://serversupportforum.de/threads/mod_fcgid-oder-mod_php5.43056/.
Aber ich würde dir auch zu CGI raten. Falls der Server überlastet erscheinen sollte, FCGI ausprobieren.
In manchen Fällen kann SuPHP auch eine Option sein.
Diesen habe ich auf ein paar Servern im Verbund mit dem eAccelerator und es läuft recht rund.

 

[Spin-Doc]

Bei mir zieht ein php-cgi Prozess im Schnitt ca. 20MB Speicher (writeable/private Wert von pmap). Das zieht der Prozess egal ob er als cgi oder fastcgi läuft.

Bei cgi kommt halt dazu - wie schon weiter oben geschrieben wurde - das für jede Anfrage einer neuer Prozess gespawnt wird. Jetzt lass mal gleichzeitig 25 Anfrage per CGI reinkommen. Allein schon die Ressourcen die hier verbraten werden um diese Prozesse zu starten liegt jenseits von Gut und Böse.

Das Volllaufen des Speichers wird bei beiden verhindert, bei cgi weil der Prozess nach Ausführen beendet wird, bei fastcgi durch das solide Prozessmanagement durch mod_fcgid.

cgi lohnt sich in meinen Augen wirklich nur bei extrem wenig Anfragen an den Webserver oder extrem wenig System Ressourcen (und da zähle ich jetzt 1GB Ram nicht dazu )

Probiers einfach aus, und melde dich wieder

FastCGI ist der riesen Ressourcenfresser, da dieser sich nen haufen Ressourcen reserviert.

Bitte erläutern

 

[d4f]

Betrieb über Module kommt nicht in Frage, da ich suexec einsetzen will.

Du kannst auch mod_php mit mpm_itk kombinieren.

 

[Bachsau]

MPM?!? ... *inshandbuchguckt* ... ok.

Apache regelt das Multi-Processing über Module. Während "Prefork" Unix-Forks einsetzt, arbeitet "Worker" wohl mit Threads, ist dann also mehr für Windows-Umgebungen gedacht, oder?

mpm-itk... *google* ist wohl nicht teil der Apache-Distribution. Okay, als ich darüber gelesen hab, dacht' ich erst: Wow, die perfekte Lösung. Aber irgendwie auch nicht:

• Forkt den Apache für jeden Request.
• Die Forks laufen zunächst als root.
• Apache selbst hat Schreib- und Leserechte auf alle Dateien des vHost-Besitzers.
• Gleichzeitige Zugriffe auf verschiedene vHosts über eine Verbindung führen zum Abbruch der Selben.

Das klingt alles nicht sehr schön.

Wegen MPM: "Event" scheint mir laut Apache-Handbuch eine gute Idee zu sein, weil es die Vorteile von Threads und Forks kombiniert. Allerdings ist es als experimentell gekennzeichnet. Setzt das jemand hier ein?

 

[Roger Wilco]

Während "Prefork" Unix-Forks einsetzt, arbeitet "Worker" wohl mit Threads, ist dann also mehr für Windows-Umgebungen gedacht, oder?

Nein. Das Worker MPM bedient sich einer Kombination aus Prozessen und Threads, um Anfragen abzuarbeiten.

Wieso sollte das nur (oder "besonders") für Windows-Systeme geeignet sein?

Wegen MPM: "Event" scheint mir laut Apache-Handbuch eine gute Idee zu sein, weil es die Vorteile von Threads und Forks kombiniert. Allerdings ist es als experimentell gekennzeichnet. Setzt das jemand hier ein?

Ja, ich. Das "experimentell" kannst du gedanklich inzwischen streichen. Ab Apache httpd 2.4 wird das Modul als stabil markiert und als bevorzugtes MPM ausgeliefert werden.

 

[Spin-Doc]

Apache regelt das Multi-Processing über Module. Während "Prefork" Unix-Forks einsetzt, arbeitet "Worker" wohl mit Threads, ist dann also mehr für Windows-Umgebungen gedacht, oder?

Nein, wie kommste denn darauf? Ganz allgemein kannste sagen, dass worker (im Vgl. zu prefork) das beste Verhältnis aus Leistung/eingesetzt Ressourcen hat. Also das was du suchst.

Mit den anderen workern (event, itk, peruser) konnte ich bisher noch keine weitreichenden Erfahrungen machen.

 

[d4f]

Forkt den Apache für jeden Request.

Das macht Apache Prefork auch, bei mittleren Seiten ist der Ressourcenverbrauch nicht all zu hoch. MPM_ITK muss zwingend forken da man nicht mehrere Threads einer PID unter verschiedenen Benutzer laufen lassen kann.
Allerdings setzt auch mpm_itk afaik auf cow (copy-on-write) was somit den Fork-Overhead verkleinert.

Die Forks laufen zunächst als root.

Root ist wegen setuid() Pflicht, man muss davon ausgehen und hoffen dass Apache selbst kein Sicherheitsloch enthaelt. Allerdings ist ein sicherer chroot immer angebracht

Apache selbst hat Schreib- und Leserechte auf alle Dateien des vHost-Besitzers.

Da der vHost-User idR nur fuer eben diesen vHost angelegt wird (werden sollte), ist das nicht weiter schlimm.

Gleichzeitige Zugriffe auf verschiedene vHosts über eine Verbindung führen zum Abbruch der Selben.

Waere mir neu das Browser ueber eine keep-alive'd Verbindung mehrere Domains aufrufen. Klingt imho ziemlich "broken by design" auf Browsersite.

Einen "perfekten" MPM wirst du nie finden

 

[Roger Wilco]

Das macht Apache Prefork auch

Das macht der Apache httpd mit Prefork MPM natürlich nicht! Richtig ist, dass ein Prozess blockiert ist, bis die gerade zu verarbeitende Anfrage komplettiert ist, aber es wird nicht bei jeder Anfrage ein neuer Prozess geforked. Auch wird ein Prozess nicht nach nur einer verarbeiteten Anfrage beendet, sondern wiederverwendet.

Ich empfehle die Lektüre von http://httpd.apache.org/docs/current/en/mod/prefork.html#how-it-works

Allerdings setzt auch mpm_itk afaik auf cow (copy-on-write) was somit den Fork-Overhead verkleinert.

Das macht nicht das ITK MPM, sondern das Betriebssystem.

 

[Bachsau]

Wieso sollte das nur (oder "besonders") für Windows-Systeme geeignet sein?

Weil Windows AFAIK nicht forken kann?

Ja, ich. Das "experimentell" kannst du gedanklich inzwischen streichen. Ab Apache httpd 2.4 wird das Modul als stabil markiert und als bevorzugtes MPM ausgeliefert werden.

Also meinst du, ich kann & sollte das einsetzen?

Das macht Apache Prefork auch, bei mittleren Seiten ist der Ressourcenverbrauch nicht all zu hoch.

Siehe Post von Roger Wilco. So hatte ich das auch verstanden, dass "Prefork" Prozesse wieder verwendet, nachdem sie fertig sind.

MPM_ITK muss zwingend forken da man nicht mehrere Threads einer PID unter verschiedenen Benutzer laufen lassen kann.

Aber unter der Gleichen.
Macht er aber nicht, weil er wohl erst forked, und dann parsed.

Root ist wegen setuid() Pflicht.

Was noch lange nicht heißt, dass es gut ist.

Da der vHost-User idR nur fuer eben diesen vHost angelegt wird (werden sollte), ist das nicht weiter schlimm.

Doch. Weil es ja nicht nur der betreffende User ist, der seine Website verwendet. Entzieht er einer seiner Dateien die Leserechte für "Welt", kann der Apache diese Datei in der Regel nicht mehr ausliefern, und darauf schreiben schon gar nicht. Läuft der Apache selbst unter seiner Kennung, hat der User keine Handhabe mehr, das zu verhindern, von .htaccess und Ablegen außerhalb des DocumentRoot mal abgesehen.

Wäre mir neu das Browser ueber eine keep-alive'd Verbindung mehrere Domains aufrufen. Klingt imho ziemlich "broken by design" auf Browsersite.

Steht als Warnung auf der Website von mpm-itk.
Ist auch gar nicht "broken by design", sondern macht Sinn. Effektiv steht die Verbindung ja zur IP-Adresse, nicht zum Hostname. Warum sollte man eine Neue aufmachen, nur weil der zu übertragende Hostname-Header sich ändert? Ergibt aus technischer Sicht eher wenig Sinn.

Das macht nicht das ITK MPM, sondern das Betriebssystem.

fork() ist ein Systemaufruf, oder? Kann man das "Wie" dabei überhaupt beeinflussen?

 

[d4f]

Weil Windows AFAIK nicht forken kann?

Windows unterstuetzt POSIX durch das InterIX-Subsystem (ab Vista/2003 als 'SUA' bekannt)
Alternativ gibt es emulierte Posix-Umgebungen wie cygwin.

Das macht der Apache httpd mit Prefork MPM natürlich nicht! Richtig ist, dass ein Prozess blockiert ist, bis die gerade zu verarbeitende Anfrage komplettiert ist, aber es wird nicht bei jeder Anfrage ein neuer Prozess geforked.

Mein Fehler

Macht er aber nicht, weil er wohl erst forked, und dann parsed.

Dann muesste der Hauptprozess dem Fork die einzelnen Client-Connections zuteilen da er ja nicht bei verfuegbaren Ressourcen eine x-beliebige Anfrage bearbeiten kann.

Doch. Weil es ja nicht nur der betreffende User ist, der seine Website verwendet. Entzieht er einer seiner Dateien die Leserechte für "Welt", kann der Apache diese Datei in der Regel nicht mehr ausliefern, und darauf schreiben schon gar nicht. Läuft der Apache selbst unter seiner Kennung, hat der User keine Handhabe mehr, das zu verhindern, von .htaccess und Ablegen außerhalb des DocumentRoot mal abgesehen.

Ich dachte immer dass man einen Webserver zur Datenauslieferung benutzt und nicht um eben das nicht zu tun. Was im DocumentRoot ist sollte auch erreichbar sein ausser es sei eben durch htaccess o.ae. verboten.

Warum sollte man eine Neue aufmachen, nur weil der zu übertragende Hostname-Header sich ändert? Ergibt aus technischer Sicht eher wenig Sinn.

Um inhaltlich zu trennen. Zumindest fuer SSL-Verbindungen muss er es ja so oder so machen...

fork() ist ein Systemaufruf, oder? Kann man das "Wie" dabei überhaupt beeinflussen?

Ok so langsam sollte ich ins Bett
Natuerlich ist fork() ein syscall und auch nicht weiter beinflussbar.

 

[Bachsau]

Habe den Apache jetzt mit Worker und mod_cgid installiert. Ich denke das ist zur Zeit das beste. Wenn die Last steigt, kann man immernoch FastCGI in Erwägung ziehen. Bei mehreren vHosts, von denen jeder für sich nur wenig Zugriffe hat, lohnt es sich nicht, so viele Prozesse laufen zu lassen.

PHP5 habe ich über ScriptAlias > Action > AddHandler eingebunden, funktioniert auch prächtig. Kann ich das mit Perl oder Python auch so machen, oder bleibt da nur der Weg über ExecCGI und Shebang?

 

[Bachsau]

Hab noch 'ne Frage: Kann ich PHP z.B. per Umgebungsvariable oder so anweisen, eine vHost-Spezifische ini-Datei einzulesen? Möglichst zusätzlich zur Grundkonfiguration?