eaccelerator-0.9.5-beta2 und fastcgi geht das zusammen?

[Anonymous]

hätte gerne mal ein paar Erfahrungsberichte zu dem Thema oder cached fastcgi die phpscripte auch schon?

[golloza]

* Is eAccelerator working with php-cgi or php-cli?
This is not yet supported and it won't be supported in the near future.

Gleiches wird für fcgi gelten.

[Joe User]

APC ist kompatibel mit PHP-FCGI...

[andreask2]

http://lighttpd.net/ z.B. setzt selber Lighttpd + PHP/FastCGI + PHPAccelerator ein. Bei neueren PHP-Versionen würde ich allerdings zu PECL::APC raten, der ja demnächst auch in die PHP-core Distribution integriert wird.

siehe auch: http://trac.lighttpd.net/trac/wiki/Tuto ... andfriends

[Anonymous]

@Joe User
APC = eaccelerator?

Eure Sichtweisen sind ja recht bunt :-)

Ich sehe es mal von der Perspektive, dass php5.1.x als fastcgi mit eaccelerator laufen tut.

Hat jemand andere Erfahrungen?

[ephigenie]

Ich hab lighttpd + php5.1.x + eA 0.9.5 - beta2 recht zuverlässig auf einem Staging - Server laufen.

Der Server wickelt seit kurzem auch ein phpAdsNew mit >90 hits/s ab.
(war nur ein Test-Setup, das aber überraschend stabil läuft)...

[Anonymous]

Was ist ein phpAdsNew?

[Roger Wilco]

http://www.google.de/search?q=phpAdsNew

[Joe User]

@Joe User
APC = eaccelerator?

Nein, http://pecl.php.net/package/APC

[Anonymous]

aha, danke
was gibt's sonst noch für Unterschiede zwischen den beiden Bewerbern, APC + eaccelerator?

Ich vermute mal, dass beide richtig gut dynamische Seiten cachen können und sonst?

[braindead]

Nein, APC ist nur ein PHP opcode Cache.

[andreask2]

was gibt's sonst noch für Unterschiede zwischen den beiden Bewerbern, APC + eaccelerator?

eAccelerator ist aus dem TurckMM Cache hervorgegangen, dem damals vermutlich besten und beliebtesten Cache für PHP 4.3. Der Autor hat die Entwicklung aber irgendwann eingestellt und ist zu Zend gegangen. Mit neueren PHP-Versionen hat dann der Turck Cache halt irgendwann nicht mehr funktioniert, und ne ganze Zeit später wurde dann von anderen Leuten auf Basis des Turck Cache, eAccelerator entwickelt. Der erhielt dann auch eine mäßige PHP 5.0 Unterstützung, neuere Beta-Versionen kommen auch halbwegs mit PHP 5.1 klar.

Leider habe ich bisher mit jeder eAccelerator Version Probleme gehabt, vor allem weil ich in der Regel sehr aktuelle PHP-Versionen verwende, und ziemlich viele, größere Bibliotheken.

APC auf der anderen Seite war früher immer viel langsamer als die anderen Caches, wurde dann irgendwann ein offizielles PECL Projekt, und ordentlich überarbeitet. Irgendwann sind immer mehr große Projekte auf APC umgeschwenkt, vor allem Yahoo und sowas, wodurch dann einige bekannte PHP-Core Entwickler wie Rasmus Lerdorf, Ilia Alshanetsky, Marcus Börger... eine komplette PHP 5.1 Unterstützung von Grund auf eingebaut haben, und den Cache laufend weiter verbessern, bzw. an Änderungen am PHP-Core anzupassen. APC war die letzte Zeit sicher eines der aktivsten PECL Projekte. Es gibt auf jeden Fall auch im APC noch ein paar bekannte Bugs, betreffen aber in der Regel nur sehr selten vorkommenden Code. Es gibt auch die Möglichkeit problematische Skripte vom Caching auszunehmen.

Abgesehen davon wird APC mit PHP6 in den PHP-Core integriert, wird also ein fester Bestandteil von PHP. Dokumentation unter php.net gibt es schon: http://de3.php.net/apc

Unterm Strich würde ich für PHP4 vielleicht noch eAccelerator verwenden, für PHP5 auf jeden Fall APC. Man kommt aber nicht drum herum mit dem eigenen Code zu testen. Einen Cache der 100%ig mit allen Syntax-Konstellationen funktioniert gibt es leider noch nicht. Ich würde aber behaupten, dass der APC hier näher dran ist und die bessere Basis hat. Die letzten APC Versionen liefen bei mir ohne jegliche Probleme.

Ich vermute mal, dass beide richtig gut dynamische Seiten cachen können und sonst?

Das ist wie gesagt ein bisschen abhängig von der PHP-Version und vom verwendeten Quellcode. 100% fehlerfrei sind beide Caches nicht. Von der Performance her nehmen die beiden sich nicht viel.

eAccelerator verfügt auch über einen Encoder, wobei hier mein letzter Stand ist, dass dieser mit PHP5 nicht funktioniert.


Viele Grüße
Andreas

[Anonymous]

Super, perfect davon lebt ein Forum. Danke!

Das macht mit ja wieder Mut dieses Forum doch noch zu besuchen. Gestern bin ich mit meiner zweiten Frage zu fastcgi sofort verbannt worden. Hier http://www.rootforum.org/forum/viewtopi ... tcgiserver ... Naja, der Admin hat sich ja auch ganz schön verwirren lassen :-)

Hast Du vieleicht noch eine gute Installationsanleitung für APC ? Da sich APC ja ganz vernümftig anhört werde ich es mal ausprobieren.

Gruß tom

[andreask2]

Hast Du vieleicht noch eine gute Installationsanleitung für APC?

http://de3.php.net/apc#apc.installation

Da sich APC ja ganz vernümftig anhört werde ich es mal ausprobieren.

kann ich wie gesagt nur empfehlen!

[ekle]

ich knüpf hier mal mit meinem Problem an, da es hier schon um das Thema geht.
ich hab php5.1 als fcgi mit suphp in Verwendung.

zuerst hatte ich den eAccelerator installiert. Der lief dann laut phpinfo(). Aber der hat mir dann immer angezeigt "Cached Files 1". Diese eine Script war dann immer das, wo mir das "Cached Files 1" angezeigt hat.

Nachdem es einfach nicht laufen wollte hab ich APC installiert. Hab aber auch hier das gleiche Ergebnis wie in eAccelerator. "Cached Files 1" laut der mitgelieferten apc.php.

Ich bin echt am rätseln an was das liegen könnte. Verzeichnisse Rechte sind schon auf 777 und laut phpinfo() läufts, nur halt mit immer nur einem Script im Cache, was ja recht sinnlos ist.

Hier die Config die ich verwendet hab: http://eklenet.de/cache.txt

[kase]

Wenn du suphp verwendest, dann hast du eine php-CGI und keine php-FCGI Konfiguration. Mit php-CGI funktioniert allerdings weder der eine noch der andere "Cacher". Du solltest auf mod_fastcgi, mod_fcgid oder mod_php umsteigen, wenn du unbedingt einen phpaccelerator verwenden willst.

[ekle]

suphp verwendet als php-Interpret /usr/bin/php5.1-fcgi.
und der geht auf einen php-server der ständig als Daemon läuft.
Das funktioniert so auch jetzt schon Jahre.

Aber wenn des mit suphp grundsätzlich nicht funktioniert in meiner config, würde das erklären, warum ichs nicht hinbekomme.

[kase]

Das hat nichts mit suphp zu tun, sondern liegt wie gesagt an php-CGI.

Jedes FCGI Binary kann auch als CGI gestartet werden, und nichts anderes macht suphp. suphp startet dein php Binary /usr/bin/php5.1-fcgi im "Modus" CGI, und beendet sich nach jedem Request wieder. Wenn du genügend Zugriffe hast, sieht es natürlich so aus, als würde dein PHP-Binary ständig im Speicher bleiben, dies ist aber definitiv nicht der Fall.

Das ist übrigens auch exakt der Grund, warum du immer GENAU 1 Cached File hast, da dein PHP immer nur genau 1 Request lang läuft, sprich immer genau eine File cached und sich dann wieder beendet.

suphp kann defintiv kein fastcgi, da es ein php-cgi Modul ist, die "normalen" fastcgi Module für den Apache sind mod_fastcgi und mod_fcgid, die würden dann dein PHP-Binary auch wirklich persistent im Speicher halten, und entsprechend dann auch mehr als 1 File cachen.

[rootsvr]

Ich schmeiss einfach mal xcache als Alternative ein, das werkelt bei mir problemlos und performant in eine fastcgi Umgebung.