Magento mit SSL und Varnish

Varnish arbeitet ausschliesslich mit HTTP Verbindungen. Um Magento mit Turpentine und Varnish mit SSL Verschlüsselung zu verwenden sind einige Eingriffe notwendig.

Wir gehen hier von einem NGinx frontend Server und einem Apache2 backend Server aus.

1.
Im NGinx zusätzlich zu der Varnish Proxy konfiguration der Parameter Ssl-Offloaded „1“ gesetzt werden:

2.
In der .htaccess Datei von magento wird der Header abgefragt:

3.
Im Magento unter System-> Configuration -> Web -> Secure muss der Offloader header Wert auf HTTP_SSL_OFFLOADED gesetzt werden. Die Base URL muss das https Protocoll verwenden.

 

BCC automatisch setzen mit Postfix

Postfix Version 2.1 kann automatisch einen BCC (Blind Carbon Copy) setzen.

Der Konfigurationsparameter recipient_bcc_maps wird dazu verwendet.

Szenario:

Alle Mails von Benutzer1 sollen automatisch per BCC an Benutzer Archiv geschickt werden.

 

Es wird eine Datei /etc/postfix/recipient_bcc angelegt:

Mit postmap wurd eine Hash Datei erzeugt

Damit Postfix diese Datei liest und berücksichtigt muss sie noch in der main.cf eingebunden werden:

 

Upgrade von Redmine

Redmine ist ein, auf Ruby on rails baiserendes, Projektmanagement und Ticketsystem.

Es ist opensource und erfreut sich allgemeiner Beliebtheit.

Da Redmine sehr intensiv weiterentwickelt wird kommt es häufig vor, dass Updates eingespeilt werden müssen.

Um ein Upgrade von Redmine durchzuführne geht man wie folgt vor:

  1. Sourcecode auf den aktuellen Stad bringen
    Wer den Quellcode per svn ausgecheckt hat kann sich glücklick schätzen denn hier ist das Upgrade sehr einfach:
    Damit wird Redmine auf den aktuellen Stand Ihrer Vollversion aktualisiert z.B. von 3.1.1 auf 3.1.2
    Wenn Sie auf eine aktuelle Vollversion aktualisieren möchten verwenden Sie den switch Befehl:
    Hiermit werden alle Dateien auf den Stand der derzeit aktuellen 3.1 Version aktualisiert. Ihre settings werden dabei nicht überschrieben.
    Wer kein Subversion verwendet hat, kann z.B. fertige Pakete herunterladen und die in einen neuen Ordner entpacken. Danach /files, /plugins und Konfigurationdateien aus dem alten Ordner kopieren.
  2. Nun müssen die notwendigen Gems nachinstalleirt bzw. aktualisiert werden
    Das Bundle Script aktualisiert bzw. installiert
  3. Aktualisieren der Redmine Datenbank
    Führt das Script zum Migrieren der Datenbank aus
  4. Aktualisieren der Redmine Plugin Datenbanken
    Migriert die Datenbanken der Plugins
  5. Temporäre Dateien löschen
    Dadurch werden temporäre Sessions gelöscht.
  6. Redmine Instanz neu starten

 

HHVM schickt PHP Webseiten auf die Überholspur

Über 80% aller Webseiten weltweit werden mit PHP betrieben.

Der schnelle Einstieg in die Programmiersprache sorgt für eine große Beliebtheit bei den Programmierern. Ob quick&dirty oder sauber objektorientiert. Alles ist möglich.

Große CMS oder Shopsysteme nutzen PHP. Module für verschiedene Datenbanksysteme stehen zur Verfügung um Daten aus PHP heraus zu verwalten.

Mit fast jedem PHP Update wurde die Programmiersprache schneller aber um gruße Shop mit tausenden von einzelnen PHP Dateien zu betreiben fehlt es teilweise doch noch an der nötigen Performance. Denn im Netz gilt: Je schneller eine Seite desto geringer die Absprungrate der Besucher.

Also wird um jede Millisekunde gefeilscht.

Es gibt verschiedene Ansätze um die Geschwindigkeit von PHP Anwendungen zu steigern:

  1. Optimieren von Code
  2. Caching von Daten
  3. Caching von Code

Wir gehen davon aus, dass der Code optimal läuft da wir uns nur mit 1 und 2 beschäftigen wollen.

Caching von Daten

Um Daten zu cachen gibt es verschiedene Möglichkeiten. Anwendungen legen Daten im Dateisystem oder Speicher ab und greifen auf diese zu um sie nicht erneut berechnen zu müssen. Memcached wird dazu gerne verwendet. PHP kann über Memcached Daten im RAM Speicher ablegen und sehr schnell darauf zugreifen.

Varnish ist ebenfalls ein beliebter Seitencache. Damit brauchen Webseiten nicht bei jedem Aufruf neu berechnet zu werden sondern werden aus einem Cache heraus ausgeliefert.

Caching von Code

Eien PHP Datei wird vor jedem Ausführen in einen Bytecode übersetzt. Wenn man nun eine PHP Datei häufig benötigt könnte man diesen Bytecode auch in einen Cache ablegen um die Zeit des Übersetzens zu sparen (OpCode Cache).

Die PHP Beschleuniger können neben dem Cachen des Bytescodes auch noch Optimierungen vornehmen und die Geschwindigkeit nochmals zu steigern. Es gibt verschiedene OpCode Caches (eAccelerator, APC, Zend OpCache).

Was ist nun HHVM?

HHVM (HipHopVirtualMachine) ist ein eigenständiges Programm welches PHP Dateien zunächst in einen ByteCode übersetzt (HHBC). Dieser ByteCode wird dynamisch zur Laufzeit durch eienn  Jit Compiler in Maschinencode compiliert. Da HHVM hierzu eine eigene PHP Implementation hat werden ggf. nicht alle Funktionen der normalen PHP Version unterstützt.

Auf diese Weise kann eine PHP Anwendung innerhalb von HHVM um ein vielfaches schneller und ressourcensparender laufen als innerhalb eines normalen PHP Interpreters.

Möchten Sie einen HHVM Server nutzen? Kein Problem. Auf unseren Root-, Managed, SVN- und Git sowie Shophosting Servern können wir Ihnen gerne einen HHVM einrichten.

Wenn Sie Fragen haben schreiben Sie uns

Vorteile einer Cloudumgebung für Magento

Die technischen Anforderungen an einen Magento Onlineshop sind stets dieselben. Die Kunden erwarten eine hohe Verfügbarkeit, eine gute Performance und einen optimalen Schutz ihrer persönlichen Daten. Aus der Perspektive des Shopbetreibers ist darüber hinaus wichtig, dass die Hardwareressourcen jederzeit einem steigenden Bedarf angepasst werden können, ohne den Betrieb für ein Serverupgrade zu unterbrechen. Cloudhosting drängt sich als Antwort auf diese Herausforderungen geradezu auf, weil seine grundlegende Idee in der Hardwareabstrahierung besteht. Rechenleistung und Storage werden dabei als Services verstanden, die unabhängig von einer konkreten Hardware zur Verfügung gestellt werden.

Redundante Infrastruktur

Vorteile einer Cloudumgebung für Magento shop hostingDas wichtigste Konzept der Ausfallsicherheit von IT-Systemen ist und bleibt die Redundanz. Sämtliche Hardwarekomponenten sind mehrfach vorhanden, um defekte Teile sofort überbrücken zu können. Dazu wird zunächst eine leistungsfähige Enterprise Plattform benötigt, die ausreichende Hardwareressourcen zur Verfügung stellt, um einzelne Ausfälle ohne Einbußen bei der Performance kompensieren zu können. Eine redundante Infrastruktur ist jedoch deutlich mehr als nur ein Ersatzteillager. Redundanz bedeutet in der IT, dass defekte Komponenten ohne Betriebsunterbrechung automatisch überbrückt werden. Dazu muss nicht nur die Hardware redundant ausgelegt sein, sondern auch alle Daten und laufenden Prozesse müssen dupliziert werden. Ein angenehmer Nebeneffekt der Redundanz besteht darin, dass sämtliche Daten auch zwischen den Datensicherungen mehrfach vorhanden sind. Somit sind im Ernstfall auch neue Kundendaten, die seit der letzten Sicherung gespeichert wurden, nicht verloren. Natürlich ist die alte Regel, dass redundante Datenträger kein Backup ersetzen, weiterhin uneingeschränkt richtig. Aber redundante Datenträger können so manches Rollback ersparen, das immer mit Datenverlusten verbunden ist. Magento verfügt zwar über eine sehr gute Rollback-Funktion – aber nutzen möchte man sie doch lieber nicht!

Cloudhosting ist den Alternativen überlegen

Vorteile einer Cloudumgebung für Magento shop hostingÜber welche Alternativen müssen wir hier überhaupt sprechen? Sicher nicht über den selbst betriebenen Server. Dieser Weg kommt allenfalls für große Unternehmen mit eigenem Rechenzentrum in Betracht. Für die Mehrzahl der Shopbetreiber kommt jedoch der interne Serverbetrieb ohnehin nicht infrage, weswegen die einzige wirkliche Alternative in der Anmietung eines realen Servers statt eines virtuellen Servers besteht. Das Rechnen in der Cloud kann in diesem Vergleich auf zahlreiche Vorteile verweisen. Hardwareressourcen unserer Enterprise Plattform können jederzeit bedarfsgerecht zugewiesen werden, außerdem garantieren wir in unserem Paket VMWare Gold eine extrem hohe Verfügbarkeit von 99,99 Prozent, die durch die Redundanz der Plattform ermöglicht wird. Der Unterschied zwischen 99,9 Prozent und 99,99 Prozent Verfügbarkeit ist übrigens keine reine Zahlenspielerei, an der nur Nerds ihren Spaß haben. Dieser Unterschied bedeutet knapp acht Stunden weniger Ausfallzeit pro Jahr – wie viele Kundenkontakte sind das bei Ihnen? Diesen zahlreichen Vorteilen steht als einzige Einschränkung gegenüber, dass das managed Cloudhosting keinen Root Zugriff erlaubt. Für Softwareentwickler kann das ein Problem sein, aber kaum für einen Shopbetreiber. Dafür werden Sicherheitsupdates im Betriebssystem automatisch eingespielt.

Einige Worte zur Datensicherheit

Secured Online Cloud Computing Concept with Business Man protectNicht zuletzt durch eine indifferente Berichterstattung der Medien wird allein schon der Begriff „Cloud“ oft mit Datenschutzproblemen assoziiert. Bei genauerem Hinsehen wird schnell klar, dass die meisten der bekannt gewordenen Probleme nicht technischer Natur sind. Problematisch ist eher, dass viele große Anbieter amerikanischem Recht unterliegen und daher den US-Behörden Hintereingänge öffnen müssen. Aus technischer Sicht bieten professionelle Rechenzentren zweifelsohne einen besseren Schutz gegen externe Angriffe, als ein normales Unternehmen selbst gewährleisten könnte. Mit Cloud oder Nicht-Cloud hat das Ganze wenig zu tun, sondern nur mit können und wollen!

Checkliste Domainumzug

Wer ein Webhosting Paket hat benötigt eine Domain damit die Webseiten erreichbar sind.

Die Domains werden von einer zentralen Registrierungsstelle verwaltet. Bei .de Domain macht dies z.B. die Denic. Möchte jemand nun eine Domain haben z.B. meinname.de kann deise Domain gegen eine jährliche Gebühr von der Denic gemietet werden. Dies geschieht in der Regel bei dem Hoster, der auch das Webpaket vermietet. Der Hoster verbindet dann die Domain mit dem Speicherplatz damit ein Aufruf der Domain im Webbrowser dann auch zu Ihren Speicherplatz führt.

Eine Domain wird nur vermietet und nicht gekauft d.h. im Falle von Problemen (z.B. Markenrechtsverletzungen) kann die Registrierungsstelle die Domain wieder von Ihnen zurückholen.

Wenn Sie mit den Leistungen Ihres Hosters nicht mehr zufrieden ist, die Domain jedoch behalten möchten, können Sie die Domain auch zu einem anderen Hoster umziehen. Für diesen Umzug sind einige Dinge zu beachten um einen schnellen und Reibungslosen Transfer zu garantieren.

Checkliste für einen erfolgreichen Domainumzug

Damit Sie keine Probleme beim Umzug haben, haben wir Ihnen hier eine Checkliste zusammen gestellt:

  1. Sorgen Sie immer dafür, dass Ihre Daten, die bei der Registrierungsstelle der Domain hinterlegt sind, aktuell sind (E-Mail Adresse, Adresse, Telefon)
    Manche Registrierungsstellen senden Ihnen bei einem Umzug eine Bestätigungsmail. Wenn diese nicht Bearbeitet wird, ist kein automatischer Umzug möglich und es ist ggf. notwendig, dass Sie das Vorhaben per Fax authorisieren.
  2. Besorgen Sie sich von Ihrem alten Webhoster den AuthCode Ihrer Domain.
    Viele Registrierungsstellen bieten eine automatischen Domaintransfer per AuthCodes. Sie authorisieren sich gegenüber der Registrierungsstelle über diesen AuthCode.
  3. Nachdem Punkt 1 und 2 abgearbeitet sind, kann das neue Paket bestellt werden.
  4. E-Mail Adressen im neuen Paket sowie Webseiten auf den neuen Speicherplatz umziehen
  5. Domainumzug durch den neuen Hoster starten.
    Ein Domainumzug dauert ja nach Registrerungsstelle wenige Stunden bis einige Tage. Da mehrere Stellen bei einem Domaintransfer kooperieren müssen kann es leider immer wieder zu Wartezeiten kommen.

Nachdem der Domainumzug gestartet wurde, werden die Daten des alten Webhosters aus der Domain gelöscht und der neue Anbeiter Ihres Webpaketes trägt sich in die Domain ein damit der neue Speicherplatz bei dem Aufruf im Browser aufegrufen wird.

Dieser Vorgang (Änderung der DNS Daten) kann mehrere Stunden dauern. Die Registrierungsstelle ändert die DNS Daten und die verschiedenen Internetanbieter holen sich diese Daten in regelmäßigen Abständen ab. Es kann also sein, das einige die Webseite ebreits auf den neuen Server erreichen  und andere noch auf dem alten Server landen. I.d.R. ist der Vorgang jedoch innerhalb von 24 Stunden abgeschlossen und alle sollten die Seite bei dem neuen Anbieter erreichen.

Mögliche Probleme bei Domainumzügen

  1. Die Adressdaten der Domain sind nicht korrekt. Bestätigungsmails konnten daher nicht empfangen und abgearbeitet werden.
    Setzen Sei sich mit Ihrem neuen Anbieter für Ihr Webpaket in Verbindung. Er kann Ihnen in dem Fall ggf. Faxformulare zur Verfügung stellen um den Domaintransfer manuell zu authorisieren.
  2. Der alte Hoster gibt den AuthCode nicht raus.
    Es kann passieren, dass der alte Webhoster nicht mehr erreichbar ist und Sie deswegen nicht an den AuthCode kommen. In dem Fall bieten einige Registrierungsstellen die Möglichkeit über Ihren neuen Webhoster an den AuthCode zu kommen. Ggf. fallen dafür extra Kosten an.
  3. Der AuthCode ist nicht korrekt
    Die AuthCodes sind in der Regel nur einge Wochen gültig.

MySQL per SSH Tunnel zu einem Root- oder Managed-Server

Es kann manchmal notwendig sein, lokal einen MySQL Zugriff auf eine entfernte Datenbank zu realisieren.

Um dies zu bewerkstelligen gibt es zwei Möglichkeiten.

1. Der MySQL Server wird nach extern freigeschaltet der Benutzer bekommt externe Zurgiffsrechte
2. Man baut einen SSH Tunel zum MySQL Server auf

Punkt 1 muss vom Provider bzw. vom Verwalter der Webhosting Umgebung durchgeführt werden.

Punkt 2 können Sie selbst realisieren sofern Sie SSH Zugriff auf Ihr Paket haben. Bei unseren SVN Hosting, Shop Hosting und Server Angeboten ist das Standardmäßig inklusive.

Herstellen eines SSH Tunnels um sich mit einer Datenbank auf einem Root Server oder Managed Server zu verbinden

Per Linux:

Am einfachsten ist es über Linux

ssh logt sich also mit dem Benutezrnamen „benutzer“ auf dem Server mein-server.de ein. Lokal wird der Port 3306 geöffnet.

Alles was an den lokalen Port 3306 geschickt wird, leitet ssh über den Tunnel an dbserver.mein-server.de:3306 weiter.

Man kann sich also lokal per mysql -h 127.0.0.1 mit der Datenbank verbinden.

Per Windows (Putty)

Hier muss unter Connections->SSH->Tunnels lediglich der Port eingestellt werden.

MySQL per SSH Tunnel zu einem Root  oder Managed Server webhosting shop hosting root server managed server MySQL per SSH Tunnel zu einem Root  oder Managed Server webhosting shop hosting root server managed server

Nach dem Klick auf open wird die gewählte SSH Verbindugn geöffnet und ein Tunnel hergestellt.

Eine Verbindung an Port 3306 würde also über den Tunnal an den dbsrv.mein-server.de Port 3306 weitergeleitet werden.

Man muss lediglich darauf achten, dass der lokale Port nicht bereits vergeben ist z.B. durch eine eigene lokale MySQL Installtion.

Magento Hosting ist sehr langsam

„Mein Magento Hosting ist sehr langsam“ stand in der Mail, die vom Support geöffnet wurde.

Da dies eien sehr allgemeine Aussage ist, klärte der zuständige Mitarbeiter erstmal mit dem Kunden ab, wie sich das Geschwinigkeitsproblem äussert.

Trotz Varnish Cache, Memcached, APC kam es zu gelegentlichen hängern, die teilweise sogar die Datenbank lahm legten.

Bei einem Magento Hosting kommt es auf das Zusammenspiel aller Komponenten an

Die Analyse ergab, dass das Problem regelmäßig auftrat. Nach einiger Zeit kam es zu einem Stillstand des MySQL Servers da dieser mit Anfragen auf die Tabelle category_catalog_flat_store so beschäftigt war, dass er keine anderen Anfragen beantworten konnte. Die Laufzeiten für die Abfrage steigerte sich von 1,5 Sekunden auf teilweise über 100 Sekunden.

Der Varnish Cache hat zwar einiges puffern können jedoch ist auch der Cache irgendwann abgelaufen. In dem Fall wird dann die Seite neu berechnet. Wenn die Trägheit z.B. durch ein aufwändiges Menü erzeugt wird, muss das Menü für alle Benutzer, die in dem Augenblick online sind, neu berechnet werden. So kann es auf einen Schlag zu 20, 30 oder mehr aufwenigen Abfragen kommen. Wenn diese Abfragen dann lange dauern potenziert sich das Problem. Während der DB Server damit beschäftigt ist, laufen neu Abfragen auf, die dann in der Queue landen. So läuft innerhalb von wenigen Sekunden die Datenbank voll, bis nichts mehr geht.

Es wurden dann falsche Indexfelder in der category_catalog_store_flat Tabelle sowie der core_url_rewrites ausgemacht, die Abfragezeiten von mehreren Sekunden erzeugten. Nach dem Zurücksetzen der Indexfelder war die Laufzeit wieder bei wenigen Millisekunden.

Der Kunde bemerkte zwar die Verbesserung bemängelte jedoch weiterhin eine Trägheit, die zwar nicht mehr so schlimm war aber trotzdem nicht in Ordnung.

Oftmals befinden sich im Magento Store mehrere Fehler

Nachdem das Laufzeitverhalten mit NewRelic weiter analysiert wurde konnten am Quellcode und ind er Datenbank keine Probleme gefunden werden.

Das finden mehrere Fehler macht die Analyse immer sehr schwierig. Man hat einen Fehler gefunden und kommt nicht zum erwünschten Ziel. Es erfordert dann viel Erfahrung um trotzdem Fehler für Fehler zu finden.

Nachdem als zusätzliche Fehlerquelle der Memcached identifiziert wurde, und dieser neu gestartet wurde war das Problem jedoch behoben. Magento hat offensichtlich etwas im Memcached abgelegt was zu langen Laufzeuten geführt hat.

Am Anfang jedes Posts steht #pstarttag#

Uns erreichte von einem unserer Profi Webhosting Kunden folgende Meldung:
Auf einmal stand am Anfang jedes Posts des WordPress Blogs # pstarttag#.

Nach einiger Analyse wurde klar, dass das Plugin SEO Auto Link & Related Posts (SEO-ALRP) dafür verantwortlich war.

Nachdem das Plugin deaktiviert wurde, war das pstarttag verschwunden.

Im Quelltext sah man, dass # pstarttag# eigentlich durch <p> ersetzt werden sollte. Warum passiert das nicht?

Nachdem ich mir den Seitenquelltext angesehen habe war es klar. Im # pstarttatg# hat sich ein Link eingeschmuggelt statt # pstarttag# stand dort dann #<a href=““></a>pstarttag#. Somit funktionierte das str_replace nicht mehr.

Nach der Analyse der Konfigurationseinstellungen vom SEO-ALRP kam ich auf die Liste der manuellen Links im Menupunkt Auto Links. Hier kann man Keywords angeben, die im Post automatisch verlinkt werden. Diese Links werden Zeile für Zeile in eine Textarea angegeben. Wenn man jedoch nach der letzten Zeile Enter drückt und somit eine leere Zeile vorhanden ist, kommt es zu dem oben beschriebenen Phänomen.

Also einfach die leere Zeile im Texteld für die manuellen Links löschen und das # pstarttag# ist verschwunden.

Magento Hosting mit Plesk 11.5, Apache, Nginx und Varnish Cache

Varnish ist ein sehr beliebter Seitencache für Webseiten.

Der Geschwindigkeitsvorteil kann je nach verwendeten Backend ein vielfaches betragen da Webseiten nicht bei jedem Abruf berechnet sondern statisch ausgeliefert werden.

Gerade im Bereich von Magento Hosting und Shop Hosting wird er sehr häufig eingesetzt.

Ich möchte hier einmal zeigen, wie man den Cache in einer Plesk Umgebung installiert.

Er wird als Daemon installiert und zwischen Webserver und Benutzer gehängt. Seiten werden entweder aus dem Cache geladen oder vom Webserver (Backend Server) abgerufen.

Um den Varnish im Plesk einzubinden sind einige Schritte erforderlich.

1. Installation des Varnish Caches
2. Erstellen einer custom Konfiguration im Plesk (CentOS: /usr/local/psa/admin/conf/templates/custom)

Installation des Varnish Caches für das Magento Hosting

Der Varnish Cache ist auf einem RH/CentOS sehr einfach installiert:

Dadurch wird der Varnish in der Version 3 installiert.

Vorsicht: Sofern andere Respoitory Varnish zur Verfügung stellen sollte mit yum priorities eine Reihenfolge festgelegt werden.

/etc/varnish/default.vcl:

/etc/sysconfig/varnish:

Erstellen einer custom Konfiguration für Plesk

Damit der Webserver von Plesk die Daten vom Varnish abruft und nicht direkt vom Webserver ist eine Konfigurationserweiterung notwendig.

Plesk ist standardmäßig so konfiguriert, dass eingehende Verbindungen vom NGinx Reverseproxy entgegen genommen werden.

Nginx liefert lokale Dateien ggf. direkt aus und übergibt weiter Anfragen an den Apache Server, welcher i.d.R. auf Port 7080 horcht. Hier klinken wir uns ein und schieben dem System den Varnish Cache unter.

Im Ordner custom können eigene Konfigurationen abgelegt werden, die Plesk statt der eigenen verwendet.

Kopieren Sie die default/nginx.php aus dem default in den custom Ordner.

Bearbeiten Sie die Datei custom/nginx.php und fügen oben (Zeile 3) zwischen den beiden PHP Zeilen den upstream backend_varnish ein:

[lokale ip adresse] ersetzen Sie bitte durch die Adresse, über die Ihre Webseite erreichbar ist.

Der Upstream Server dient nun als Deklaration, woher der NGinx seine Daten bekommen soll, sobald er als proxy_pass den Namen des Upstreams übergeben bekommen hat.

Sollte der Varnish Cache mal nicht Online sein, verwendet NGinx den Apache Server da dieser als Backup Verbindung hinterlegt ist.

Kopieren Sie die default/domain/service/proxy.php Datei in den custom/domain/service Ordner.

Bearbeiten Sie diese nun wie folgt (custom/domain/service/proxy.php):

An der file_exists Funktion läßt sich gut sehen, dass das Script erst prüft, ob eine Datei im /etc/varnish ordner liegt, die als Namen den Domainnamen gefolgt von .enable hat (z.B. lcube-webhosting.de.enable). Ist dies der Fall wird der Varnish aktiviert. Wenn nicht, werden die Dateien normal vom Webserver abgerufen. Auf diese Weise kann der Varnish durch setzen einer Datei aktiviert oder deaktiviert werden.

Nach dem setzen oder löschen der enable Datei muss

ausgeführt werden.

Ggf. muss ein Addon installiert werden. Für Magento kommt z.B. Turpentine in Frage.

Nicht für jede Anwendung ist der Varnish Cache geeignet. Wenn viele Dynamische Daten abgerufen werden und die Aktualität der Daten von entscheidender Bedeutung ist (z.B. bei Warenkörbe sowie beim SVN Hosting oder Git Hosting) sollte man entsprechende URLs in die Ausnahmen eintragen bzw. auf Varnish verzichten.