øxygen wrote:Also ich finde die Variante mit mehreren Apache Instanzen eher Suboptimal. In Umgebungen mit stark und weniger stark beanspruchten Vhosts ist die Verteilung der Threads/Prozesse zu unflexibel. Ein globales Client Limit ist so schlecht zu realisieren, auf Lastwechsel kann man nur manuell reagieren.
Da sich gleiche Prozesse auf den mordernen Linux-Systemen die Resourcen sehr effizient teilen, sehe ich da eigentlich kein großes Problem - im Gegenteil, wie flo schon sagte kann man sogar sehr gut die Resourcen der User begrenzen.
Trotzdem ist es mit ziemlicher Sicherheit immer noch ne Ecke effizienter als CGIs - man kann sogar Opcode Caches einsetzen (wenn man ausreichend RAM hat) und die vorgelagerte Apache/mod_proxy Variante zum Cachen von statischen Inhalten verwenden (oder vielleicht direkt gegen den effizienteren Squid ersetzen?)...
øxygen wrote:Außerdem kommt noch dazu, dass durch den Proxy die IP des Clients z.B. für Sessionverwaltung und Co. nur noch umständlich bzw. unkonventionell festgestellt werden kann.
Ja, das ist in der Tat ein Problem. Allerdings gibt es nicht so viele Anwendungen die sich sinnvollerweise auf Client-IP Adressen verlassen, höchtens für Dokumentations-Zwecke, gerade für Sessions ist das z.B. wenig sinnvoll.
øxygen wrote:Ich denke im Moment ist die Apache Fundation gefordert endlich die Entwicklung des perchild MPM oder eines das einen vergleichbaren Funktionsumfang hat, voran zu treiben. Auch wenn dass dann nicht so performat wie leader oder event ist, würde es sicher besser funktionieren, als für jeden VHost einen extra Apache Prozess laufen zu lassen.
Naja, perchild wurde meines Wissens schon vor einiger Zeit eingestellt (in der Apache 2.2 Doku fehlt es auch komplett), vom Metux MPM gibt es auch seit 1 Jahr keinen Release mehr (und das Patch ist für eine 2 Jahre alte Apache-Version). Das ist alles tierisch instabil, hat alle möglichen Beschränkungen (kein SSL, kein KeepAlive...) und ist sicherheitstechnisch wohl auch nicht ganz unproblematisch...
Das Neuste von der Sorte ist wohl das
PerUser MPM, das gibt es auch für Apache 2.0.55. Das verwendet keine Threads mehr, hat einen Prozess-Pool für jede UID, also technisch gesehen nicht viel anders als mehrere Apache Instanzen. Vorteile ist natürlich, dass es minimal effizienter sein könnte, da die Request nicht von einem Proxy per HTTP weitergeleitet werden, sondern per IPC. Auf der anderen Seite verwendet die Variante mit den Apache Instanzen ausschließlich sehr ausgereifte Software, das PerUser MPM dagen ist noch lange nicht stabil.
Ich halte PerUser für den sinnvollsten Ansatz, wenn das irgendwann stabil ist und gut durchdacht, wird es vermutlich die effizienteste und praktikabelste Lösung sein. Da es nicht multithreaded ist, hat man auch keine Probleme mit PHP, was Performance und Stabilität unter Last angeht...
Allerdings wundert es mich, dass so wenige Entwickler sich für diese Module interessieren... Aber vermutlich ist das ganze - vor allem bei multithreaded Webservern - auch nicht ganz so einfach zu implementieren wie es sich anhört...