Ubuntu Server: PHP, FastCGI, APC und Apache threaded
Allgemein/Internet Mai 31st, 2008Ubuntu (Server) sind prädestiniert um als Webserver eingesetzt zu werden. Apache seit Version 2 unterstützt den Modus als multithread Server zu laufen, und somit nicht einen „schwergewichtigen“ Prozeß pro Request laufen lassen zu müssen.Schwergewichtig ist auch das regelmäßige Parsen und Übersetzen von PHP Quelltexten. Daher gibt es OP-Code Caches, die den PHP Bytecode gecacht halten für die nächste Ausführung. So z.B. den Zend Cache, eAccelerator, xcache und APC.
Für die Installation von APC mit Ubuntu bzw. Debian gibt es einige Anleitungen, wie diese hier, hier und hier. In meinem Fall kommt PHP nicht als Apache Modul zum Einsatz (damit der Apache threaded laufen kann), und auch nicht als normales CGI, sondern als FastCGI.
Daher wollte ich – abweichend von den referenzierten Anleitungen – nicht APC gegen den Apache kompilieren. Hier daher meine Anleitung:
apt-get install php5-dev php-pear
Anschließend geht es dann weiter mit
pecl install apc
Hier wird dann als erstes mittels „1-1“, „no“ das Kompilieren gegen die Apache Module deaktiviert. Nun noch die APC extension aktivieren
extension=apc.so
Und die FastCGI Prozesse neu starten. APC ist bei mir bisher stabil und – natürlich – wesentlich schneller als ohne.
April 25th, 2009 at 08:46
Hallo.
Der Beitrag ist zwar schon etwas älter, die Thematik jedoch für mich brandaktuell.
Mich würde interessieren, ob bei deinem Vorgehen der APC zwischen den einzelnen fcgi-Prozessen geshared wird, oder ob für jeden Prozess ein eigener Cache erzeugt wird.
Nach langer Recherche im Netz drängt sich mir nämlich der Eindruck auf, dass APC (zumindest als lokaler, persistenter Cache) bei fcgi+Apache2 mpm ziemlich nutzlos ist, da der/die Caches geleert werden, sobald der fcgi-Prozess stirbt.
Wie sind deine Erfahrungen mit dieser Thematik? Was gewinnst du, indem du APC nicht gegen den Apache kompilierst?
Ich sag schonmal vielen Dank im voraus.
Gruß, aefxx
April 25th, 2009 at 13:24
Da es um PHP geht und PHP selber eine Prozessmanager und spawner für Child-Prozesse hat, habe ich das ganze so gelöst: Ich habe die Anzahl der (f)cgi Prozesse stark reduziert (z.B. 3) und jedem dann eine relativ große Anzahl von eigenen Prozessen genehmigt (z.B. 20). Innerhalb dieser PHP-gespawnten-Prozesse kann dann der APC gemeinsam verwendet werden.
Damit habe ich gute Erfahrungen gemacht, und ich denke das ist für dedizierte Server ein guter Weg zwischen planbaren Ressourcenverbrauch durch PHP/APC und gut ausgenutzter Ressourcen. Wenn man jedoch das als Hosting für sehr unterschiedliche Webauftritte machen möchte, hat man das Problem dass jeder Auftritt „anders“ ist und entsprechend die Anzahl der FCGI und PHP Prozesse/Kinder angepaßt werden sollte.
Hier kann es natürlich helfen, jeweils spezielle FCGI Launcher Scripte mit angepaßten Environment Settings für PHP zu verwenden, und ggf. sogar eigene php.ini Dateien. Für größeres Hosting ist FCGI jedoch in meinen Augen nicht optimal, und „normales“ CGI besser geeignet.
April 27th, 2009 at 23:18
Danke erstmal für die Antwort, everflux.
Hatte schon befürchtet, dass der Cache lediglich zwischen den Kindprozessen geshared wird.
Dein Vorschlag für dedizierte Server ließe sich sogar ad absurdum führen, indem man ganz genau EINEN fcgi-Prozess zulässt, der selbst niemals stirbt und die Arbeit des forkens dem PHP Prozessmanager überlässt.
Leidiger Weise bringt dann jedoch bereits ein einziger hängender Kindprozess das ganze Konstrukt zum Einsturz. Auch habe ich des öfteren vom unterirdischen Prozessmanagement PHPs gelesen, das nicht selten eine Reihe Weisenprozesse erzeugt, die dann mit Hilfe eines Cronjobs abgeschossen werden müssen.
Mit einem Wort: suboptimal. Hoffentlich raffen sich Rasmus und seine Entwicklerkollegen möglichst bald auf.
Adieu.