Varnish nur für Enterprise?

Hallo, ich habe folgende Frage: In der Roadmap klang es so - als ob anstelle des ProxyCache auch Varnish genutzt werden kann - lediglich mit einer Anpassung der Templates (und natürlich installierten Varnish) - siehe hier: http://wiki.shopware.de/Shopware-4-Http … l_817.html Jetzt nach dem Release sieht es für mich so aus, als ob die Varnish Unterstützung nur für den Cluster vorhanden/gedacht ist? Wie ist hier der Stand der Dinge? Gut, Varnish kann ich so oder so natürlich immer installieren und davor setzen. Nur wird es was bringen, wenn Shopware (Professional) dies nicht unterstützt? Würde mich über ein Feedback sehr freuen.

Bzw. ist das rein technisch nicht beschränkt. Zertifiziert und getestet aber nur mit Enterprise-Cluster!

Ich schaue heute Abend mal nach, wie es darum steht. Grundsätzlich müßte sich in den ESI-unterstützten Templates irgendwo im Code <include …> oder Platzhalter dafür finden. Das hatte ich in der Beta 2 im Emotion Template auch noch nicht gefunden.

In den Templates findet sich leider nichts was mit “ESI” zu tun hat. Soweit ich das ganze jetzt durchgeschaut habe, sollte es aber tatsächlich schon funktionieren, wenn die Templates entsprechend mit “ESI” ausgestattet werden - die Logik scheint auch in der Community Edition enthalten zu sein. Wenn man ganz lieb fragen würde ob man einen kommplettes Template mit “ESI” bekommen könnte. Wäre das möglich und vielleicht auch die passenden Settings für Varnish ? :oops: Die fehlen in meinem ersten genannten Shopware-Link noch (dort steht “Beispiel folgt”). Das wäre wirklich super nett. Ich denke es ist der Community schon klar das dies weder zertifiziert noch getestet ist. Aber die wenigsten werden überhaupt diese Konstellation auf ihren Servern hinbekommen (Varnish ist ja nicht grad etwas was Einsteiger bzw. kleine Shops nutzen können bzw. werden). Ich und ich vermute auch tschersich würde sich sehr freuen wenn man hier die Infos bzw. Dateien zur Verfügung gestellt bekommen könnte.

Ich hatte Varnish ja mit der 4.0 Beta 2 bereits vor einem nginx mit PHP-FPM laufen. Die ESI Settings waren drin, nur wenn das Template es nicht drin hat, bringt es wenig. Trotzdem war es rasend schnell. Ich setze nur gerade meinen Testserver neu auf und da kann ich gerade wenig tun. Die passende Varnish Config habe ich da, aber nicht griffbereit. Poste ich gern mal als Beitrag für den „Labs“ Bereich, wenn ich wieder alles „up and running“ habe.

Hi, die ESI-Tags sind auch im Standard-Template „Emotion“ schon enthalten bzw. können dort auch aktiviert werden. Dafür ist das Plugin „HttpCache“ zuständig das dafür erst installiert werden muss. Es verwandelt dann die Smarty-Action-Befehle in ESI-Tags um und setzt die entsprechenden Header für den Symfony bzw. Varnish-Cache. Weitere Informationen dazu findet Ihr auch hier schon im Beta-Guide: http://wiki.shopware.de/Shopware-4-Http … l_817.html Achtung: Damit das funktioniert, muss der Varnish den „Surrogate-Capability-Header“ übergeben und der Symfony-Proxy darf nicht über die config.php aktiviert worden sein. Heiner

Aha, das geht so aus der Wiki Seite nicht hervor. Da ging ich davon aus, dass es genau einen http-Proxy gibt, der ausgeschaltet werden muss, wenn man Varnish davor klemmt. Wenn ich es jetzt richtig verstehe, muss der http-Cache (das Plugin) an sein, damit die ESI Tags überhaupt erzeugt werden und die Header an Varnish gehen. Varnish selbst muss etwas damit anfangen können, also: sub vcl\_recv { set req.http.Surrogate-Capability = "abc=ESI/1.0"; } sub vcl\_fetch { if (beresp.http.Surrogate-Control ~ "ESI/1.0") { unset beresp.http.Surrogate-Control; set beresp.do\_esi = true; } } Der Symfony Cache (über die Config.php in ‘httpCache’ => array( ‘enabled’ => false, (…) auszuschalten??) muss dann aus sein, wenn man Varnish davor klemmt, ansonsten an stellen. Also: für ESI den http-Cache (Plugin) immer an und dann entweder Varnish oder Symfony Cache davor. Richtig?

Ja, genau. Dem Plugin/Shopware ist es egal ob man Varnish oder Symfony davor hat. Man muss nur die richtigen Header setzten bzw. auslesen in seiner Varnish-Konfiguration.

2 Likes

Hm, ich komme hier irgendwie nicht weiter - ich hab jetzt Varnish (Version 3) erstmal wieder relativ einfach konfiguriert, da ich dachte meine bisherige Config ist zu kompliziert. Hat aber nichts gebracht. In der config.php bzw. auch in der Custom.php hab ich httpCacheEnabled auf false gesetzt und debug auf true. Template ist das “Emotion Brown” Als Antwort Header erhalte ich aber nur folgendes (immer): Accept-Ranges bytes Age 0 Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0, public, max-age=3600, s-maxage=3600 Connection keep-alive Content-Length 0 Content-Type text/html; charset=utf-8 Date Fri, 31 Aug 2012 07:08:02 GMT Expires Thu, 19 Nov 1981 08:52:00 GMT Keep-Alive timeout=300 Pragma no-cache Server Apache Set-Cookie session-1=450c69633a08e2921aea0f69e8718fef1976bf14; path=/; HttpOnly Surrogate-Control content="ESI/1.0" Via 1.1 varnish X-Cache MISS X-ESI true X-Varnish 1057490551 X-XSS-Protection 1; mode=block Aus dem Cache wird quasi nichts ausgeliefert (dabei ist es sogar egal ob das eine Javascript Datei oder eben die eigentliche Page ist. Meine Vermutung liegt auf dem Cache-Control Header - wo kommt der her? Der Webserver fügt das nicht hinzu, soweit konnte ich das schon eingrenzen. Aber wie gesagt, der Varnish Cache wird nicht getroffen bzw. angelegt (Varnish funktioniert aber mit anderen Websites auf dem Server prima - da wird auch X-Cache HIT geliefert, also ist es kein Problem von Varnish direkt). Auch fehlen mir die x-shopware Debug Header - obwohl die doch eigentlich mit ausgeliefert werden sollen? Irgend eine Idee wo es da hängen kann? Muss man eigentlich um Varnish zu betreiben beim HttpCache Plugin diese Alterantive Prox-URL setzen? Wenn ja, dann würde dort doch quasi http://localhost:8080/ reichen, oder?

Hi, die NoCache-Header werden von der PHP-Session gesetzt und sollten ignoriert werden. Nur der “s-maxage” Header sollte da ein Rolle spielen. Zusätzliche solltest du noch das HttpCache-Plugin aktualisieren. Da hatten wir für die 4.0.1 noch ein paar Verbesserungen vorgenommen. Das aktuelle Plugin habe hier einmal angehangen. Einfach das alte Plugin deinstallieren und das neue Plugin hochladen + installieren. Der alternative Proxy-Pfad muss theoretisch nicht gesetzt werden. Aber wenn man z.B. mehrere Proxies im Cluster hat, macht es Sinn hier den Haupt-Proxy zu hinterlegen. Heiner