Suche opcode u. filecache Kombination

J

Johannes

New Member
Hallo & schönen guten Morgen!

Nachdem wir auf php 5.4.x umgestiegen sind war eAccelerator aus dem Rennen, APC wird auch nicht mehr upgedatet, und da wir ZendLoader haben mag er nicht mit opCache zusammenfunktionieren.

Jetzt hab ich die Frage: welche sinnvolle Kombination an opcode u. Filecache gibt es überhaupt für einen php 5.4 Server mit ZendLoader?

Als opcode caching habe ich noch apcu und xcache gefunden, was aber nehmen für Filecache?

Bin mit meinem Latein ziemlich am Ende. .. php5.5 kommt derweil leider noch nicht in Frage. Und toll wäre eine Lösung für einen development server, wir bauen dauernd Webseiten. Von memcached hab ich gehört daß der keine ACL unterstützt, wie gefährlich ist das wirklich - hab nur Widersprüchliches gefunden.. ?

System: CentOS 6.6, Php 5.4.40 (mod_php, php-fpm)

Danke!!
 
Last edited by a moderator:
Ich bin mir nicht wirklich sicher was du mit filecache in bezug auf PHP meinst. Alle Cache Varianten halten lediglich entweder Opcode oder fertige Ergebnisse vor.

5.4 ist im September sowieso EOL.

Development Server? -> 5.6.

Muss man sich noch fragen ob cacheing wärend der Entwicklung Sinn mach. OpCache/hhvm wobei bei hhvm eine mögliche Inkompatibilität zu PHP auftreten kann.

Aufhören PHP zu encoden. Es sind sowieso alle Varianten gehackt. Wenn etwas hart zu lesen sein soll die Sprache wechseln. Java/C*

Memcached lässt sich Lokal beschränken und unterstütz SASL zur Authentifizierung.
 
Last edited by a moderator:
Hi,
danke MadMakz!

Problem ist mittlerweile gelöst. Wir haben nochmals die Bedürfnisse für den ZendguardLoader gecheckt, das war nur eine Installation, auf die ist gepfiffen.. --> opcache installiert u. APCu für das was ich FileCache genannt habe, auch UserdataCache od. halt alles was nicht php sondern die Ladezeiten von Files, Images usw. betrifft...

Mit Zendloader habe ich mich viell. falsch ausgedrückt, sorry, meinte den Zendguardloader, der kann nicht mit Zend opCache. Nachdem der Zendguardloader nicht mehr nötig war, war die Kombination mit opcache u. apcu klar..

Und warum php 5.4 .. weil es das am meisten kompatible php derzeit ist *g* und meine Bängels am Server nicht rumraunzen wenn ich was neu mache..

hhvm kenn ich nicht, schau ich mir gleich an, danke für den Tipp, ebenso danke für die Info mit der SASL Unterstützung vom memcache, muß ich auch noch checken..

Danke!!
 
Wenn die OpCache Inkommpatibilität nicht binär ist, also am laden der Extension scheitert, reicht es vielleicht OpCache auf der einen ZendLoader Webseite zu deaktivieren opcache.enable = off

Was die statischen Dateien angeht, so haben alle Webserver ebenfalls eigene optionale Cache Extensions, z.B. mod_cache / mod_mem_cache bei Apache od. die Optionen open_file_cache* / proxy_cache* bei Nginx.
 
Last edited by a moderator:
Womit wir auch gute Erfahrungen gemacht haben, ist das Verfrachten eines ganzen Webprojekts in eine RAM-Disk. Extrem einfach einzurichten und schneller als jeder Cache im Webserver. Hierbei sollte man die Flüchtigkeit der Daten natürlich beachten. :) Also für Verzeichnisse, in die regelmäßig neue Daten geschrieben werden, sollte man sich was Anderes überlegen. Aber das sollte klar sein.

Ansonsten ist NGINX super als cachender Reverse-Proxy (inkl. Request- und Responsebuffering), gerade vor einem Apache würde ich das den Apache-eigenen Cachingmethoden definitiv immer vorziehen. Ein NGINX im Frontend hat ja noch diverse andere Vorteile.
 
Hallo php-Friends,

RAM-Disk hab ich hier lokal laufen, ist top-schnell, aber für den Server ist mir das noch nicht in den Sinn gekommen. Werde mal nachforschen..

Gibts eigentlich wesentliche Unterschiede zw. NGINX u. Varnish?
Nginx hat mir heute schon mein Linux-Admin vorgeschlagen, während ich bei Varnish gelandet bin (angebl. einfacher zu installieren u. weniger Konfigs, hab ich jetzt aber nur vom Hörensagen)
 
varnish kann kein SSL, müsstest also einen proxy wie nginx davor setzen was dann aber dank der hervorragenden Cacheeigensschaften von Nginx obsolet wird.

Mit dem ganzen "SSL erzwingen Trip" der Browserhersteller sehe ich keine große zukunft für Varnish am Frontend.

Der mehr oder weniger größte nachteil bei nginx ist in der Benutzerfreundlichkeit das fehlen von drop-in Konfig änderungen a la .htaccess/.htpasswd. Was uns wohl gleichzeitig zu dem größten Nachteil in sachen Sharedhosting bringt. U. a. deshalb setzen ihn viele nur als Cacheproxy zu Apache ein und nicht als kompletten Ersatz. Viele scheuen sich auch daran mod_rewrite Regeln in das gegenüber von Nginx zu übersetzen. Sogar von den weitverbreitetsten Webscripten gibt es bis heute keine offizielle Lösungen aber 500 how-to's wie man ihn als Cachefrontend für Apache einsetzt.

Ansonnsten kann ich eigentlich nur von Vorteilen sprechen.
 
Last edited by a moderator:
Danke für den Tipp! Werde mir nginx in der nächsten Session mal ordentlich ansehen. SSL würde mich weniger stören wenn die dann etwas langsamer laufen, da haben wir nur ganz wenig, die stört das glaub ich nicht.

Und nginx haben wir außerdem irgendwo so ein autoinstaller-script dazu liegen, wäre jedenfalls auch einfacher für uns zum Antesten (u. sicherer :)

Übrigens an alle: möchte mich ganz herzlich für die ganzen Kommentare bedanken, v.a. daß die echt zielgerichtet u. hilfreich sind, ist mein erstes größeres Posting hier, hab mich davor noch nicht getraut :o
Aber ich glaube jetzt werde ich öfter hier herkommen, ihr habt mir Mut gemacht!

Thx!!!
 
MadMakz said:
Mit dem ganzen "SSL erzwingen Trip" der Browserhersteller sehe ich keine große zukunft für Varnish am Frontend.
Click to expand...
Varnish bekommt HTTP2 inklusive TLS und dem ganzen anderen damit verbundenem Quatsch. Dauert halt noch etwas, schliesslich war/ist phk kein Freund von HTTP2 und hat bis zuletzt in der Workinggroup dagegen gegämpft.

Kurz: Varnish hat eine Zukunft und dank phk und Co so gar eine sehr Gute...
 
You must log in or register to reply here.
Back
Top