Reverse Proxy

[TerraX]

Hallo,

folgendes Szenario:

Ich habe 2 Projekte, welche derzeit über Apache laufen (PHP-Webanwendung). Daneben läuft mein privates Blog via Tomcat (auf Pebble-Basis). Zukünftig möchte ich jedoch statt Apache lieber den Hiawatha Webserver einsetzen. Bisher habe ich mittels AJP-Modul die Requests für mein Blog zum Tomcat durchgeleitet. Hiawatha hat so eine Proxy-Funktionalität nicht.

Auf meinen Nachforschungen bin ich auf den Reverse Proxy Pound gestoßen, der Domain-abhängig die Requests zum jeweiligen Server durchleiten würde und damit eine mögliche Lösung des Problems wäre.

Frage: Ich bin auf der Suche nach einer möglichst schmalen Lösung, die in Abhängigkeit der Domain, die Request auf Port 80 transparent zum jeweiligen Server durchleitet. Ist mein Ansatz (Pound) ein geeigneter oder gibt es noch einfachere Lösungen in Sicht Performance, Speicher-/CPU-Verbrauch?

 

[PapaBaer]

Pound ist ein reiner Balancer. Damit würdest du auch alle statischen Files über den Tomcat ziehen, was für die Performance nicht so der Renner wäre.

Besser eignet sich hier z.B. nginx. Damit kannst du auch einen revers proxy umsetzen, den statischen Content aber direkt und schnell vom nginx ausliefern lassen.

 

[TerraX]

Hmm, der Apache in der Front kann das auch. Diesen Ansatz hatte ich in der Vergangenheit schon mal versucht und war da auf Probleme gestoßen. Das in Pebble integrierte URL-Rewriting sorgt dafür, dass alle Seiten im Browser als HTML erscheinen und damit die Request auch auf .html lauten.

Daher funktionierte nur alles problemlos, wenn ich den Request ausnahmslos an Tomcat weitergeleitet habe. Mein Problem war, dass ich nicht differenzieren konnte, zwischen .jsp über tomcat und den Rest an Apache. Last but not least, ist Performance bei meinem privaten blog nicht so unbedingt die Anforderung

P.S.: andererseits, wenn ich da grade so mein Geschreibsel lese, steht ja eigentlich schon die Lösung drin ... muss ich mal in der VMWare testen ...

P.S.: hmm allerdings sehe ich grade, dass ich auch URLs habe wie http://www.tek-reality.de/addBlogEntry.secureaction#form - weil da stehe ich noch weiterhin vor dem Rätsel, wie ich das unterscheiden soll ...

 

[TerraX]

So, ich habe jetzt die Tage ein wenig herum-experimentiert. Auf jeden Fall muss ich mir den nginx-Ansatz nochmal ansehen.

Beim Hiawatha gefällt mir partout nicht, dass ich für jeden User-Webcontainer eine eigene FastCGI-Instanz aufmachen muss, was in puncto Speicherverbrauch ziemlich ineffizient ist und damit eines der angestrebten Ziele zunichte machen würde.

Falls weiteres Interesse besteht, berichte ich gern weiter und stelle die letztliche Lösung vor.

 

[virtual2]

MOD: Full-Quote entfernt!

Lasse doch PHP über CGI laufen, dass ist zwar ein wenig langsamer ist aber seitens des Sicherheitsaspektes sinnvoller.

Als reverse Proxy kann ich Nginx wärmstens empfehlen, ich betreibe einen Nginx vor 2 Hiawatha Webservern welche baldig eine etwas größere Webcommunity tragen sollen und habe bisher keine Probleme damit.

 

[TerraX]

PHP als reines CGI laufen zu lassen, kommt für mich nicht in Frage, da ich mit knappen Speicher- und RAM-Ressourcen auskommen muss. Dafür ist diese Betriebsvariante nicht hinreichend performant.

Das Gespann Pound + Hiawatha habe ich inzwischen verworfen. NGinx steht allerdings noch auf meiner Liste zum Testen. Allerdings mag mir im Moment nicht so recht einleuchten wieso ich einen Webserver wie Nginx in der Front als Load-Balancer bzw. Reverse Proxy laufen lassen sollte und dahinter Hiawatha, wenn Nginx doch eigentlich den gleichen Job macht. Es sei denn Nginx taugt als Load-Balancer/Reverse Proxy mehr als Pound.

Wobei meine festgestellten Probleme eigentlich nicht an Pound hingen sondern allesamt aus dem Bereich Hiawatha und mangelhaftes Error-Logging stammten. Ich hatte halt diverse 500er und 503er Error von Hiawatha, die ich allesamt nicht im error.log nachvollziehen konnte - sprich kein Eintrag.

 

[PapaBaer]

PHP als reines CGI laufen zu lassen, kommt für mich nicht in Frage, da ich mit knappen Speicher- und RAM-Ressourcen auskommen muss.

Das macht imho keinen Sinn. Alles außer CGI bleibt in irgend einer Form als Prozess im Speicher und braucht daher mehr RAM.

Ich hatte halt diverse 500er und 503er Error von Hiawatha, die ich allesamt nicht im error.log nachvollziehen konnte - sprich kein Eintrag.

Ressourcen-Probleme. Die bekommst du auch mit Pound nicht gelöst. Da hilft nur alle Prozesse auf Verbrauch optimieren.

 

[virtual2]

MOD: Fullquote entfernt.

Write Rechte auf die logs sauber gesetzt?

503 error -> PHP-FCGI Server nicht erreichbar -> fcgi neu starten

500 error -> PHP-FCGI children gestorben -> childrens niedriger setzen

id.R. ist das der Fall. Jedoch können 500er auch bei fehlerhaften PHP Code auftreten

 

[TerraX]

@PapaBaer:

Die Argumentation bzgl. CGI und Ressourcenverbrauch kann ich so nicht nachvollziehen - maybe unterliege ich auch einem erheblichen Denkfehler. Aber AFAIK führt bei reinem CGI jeder (parallele) Request zu einem eigenen Interpreter (mehrere Kopien im RAM). Bei FastCGI wird nur eine Interpreter-Instanz geladen und steht dann für mehrere Requests zur Verfügung.

Fazit: Die Grundlast (Belegung RAM) ist natürlich bei FastCGI höher - aber sobald mehrere parallele Zugriffe stattfinden, erzeuge ich mit CGI viel viel mehr Overhead und verbrauche damit meine Ressourcen deutlich schneller. Last but not least kann ich bei reinem CGI auch keine PHP-Beschleuniger wie APC und Co. einsetzen. mod_PHP mag ich aus Sicherheitsgründen nicht.

Ressourcen-Probleme. Die bekommst du auch mit Pound nicht gelöst. Da hilft nur alle Prozesse auf Verbrauch optimieren.

Das war auch nicht die Intention Pound bzw. generell einen Reverse Proxy einzusetzen. Ich habe einerseits 2 PHP-Projekte zu betreuen und gleichzeitig aber auch eine Java-Anwendung über Tomcat zu laufen. Bisher habe ich unter Apache dafür den entsprechenden Tomcat Connector benutzt. Jetzt wollte ich halt mal Hiawatha testen in Sachen Performance, Sicherheit ubnd Ressourcenverbrauch. Für Hiawatha gibt es keinen solchen Connector und wird es laut Entwickler auch nie geben. Nur daher brauchte ich einen Reverse Proxy in der Front. Nginx in der Front wäre auch geeignet (ohne weitere Zusätze), da bin ich aber noch nicht zum Testen gekommen.

@virtual2:

Write Rechte auf die logs sauber gesetzt?

Definitiv ja - in der access.log steht ja auch der Abruf mit dem Errorcode aber in den anderen Logs findet sich kein Eintrag mit dem man das Ereignis in Verbindung bringen könnte.

503 error -> PHP-FCGI Server nicht erreichbar -> fcgi neu starten
500 error -> PHP-FCGI children gestorben -> childrens niedriger setzen

Diese Problematik kenne ich so vom Apache2 nicht. Aber auch hier gilt das oben gesagte - in den error.logs ein Hauch von Nichts.

id.R. ist das der Fall. Jedoch können 500er auch bei fehlerhaften PHP Code auftreten

Ich weiß von 2 Stellen in einem Teilscript, wo das der Fall ist und ich noch nicht nachgebessert habe, weil nämlich der Apache in seinem error.log mit mir immer schimpft Aber was bitte geht den Webserver fehlerhafter PHP-Code an? der ist nur für die HTML-Ausgabe zuständig und wenn diese auf Grund des Fehler so verkorkst ist, dass er das nicht kann, sollte ich das auch im log sehen.

 

[virtual2]

Okay, darf der Benutzer unter dem Hiawatha läuft auch auf die logs schreiben, bzw. gehören ihm diese? Wenn das der Fall ist, sollten Fehler eigentlich geloggt werden

 

[TerraX]

Ich habe sogar testweise, den entsprechenden logs und log-verzeichnissen ein chmod 777 verpasst, um das 200% auszuschließen. Nope. Aber ich werde mir nochmal die Sache mit dem PHP-FCGI genauer ansehen.

 

[PapaBaer]

Wenn das der Fall ist, sollten Fehler eigentlich geloggt werden

Wenn kein RAM mehr da ist, dann ist er alle. Dann passt da auch kein File-Handler mehr rein.

 

[PapaBaer]

Bei FastCGI wird nur eine Interpreter-Instanz geladen und steht dann für mehrere Requests zur Verfügung.

Ja, aber auch nur für Requests, die nacheinander eintreffen. Willst du X gleichzeitige Requests, musst du auch X Interpreter-Instanzen öffnen. Die laufen aber persistent. Mit CGI brauchst du auch X Instanzen, aber die sind nach dem Request wieder weg. Heißt: Wenn du dauerhaft hohe Zugriffe hast, ist es egal. CGI ist dann nur viel langsamer. Wenn du allerdings mal auf diesem, mal auf jenem VHost hohe Zugriffe hast, verbrauchen die unausgelasteten VHosts weniger Rescourcen, weil eben keine FastCGI-Prozesse in der Luft hängen.

 

[TerraX]

Oki, soweit nachvollziehbar. Mein Szenario sieht halt so aus, dass nur ein PHP-Projekt per FastCGI bedient werden soll/muss, das andere wickelt der Tomcat ab (atm, noch komplett inkl. statischer Content - das passe ich aber noch an).

Insofern werde ich wohl Apache oder Nginx in der Front betreiben, im Gegensatz zum ursprünglich geplanten Setup.