Ich habe mir mal das 3.5.3 VMWare Image angesehen und wollte ausprobieren, ob ich das mit Memcached statt File Cache hinbekomme. An einem Punkt komme ich nicht weiter. Vielleicht könnt ihr mir helfen. Das habe ich gemacht (Debian Squeeze mit PHP 5.3.3-5): 1. Memcached und das PHP5 Modul installiert: apt-get install memcached php5-memcache
2. Check, ob der Listener läuft und ob der Port stimmt: netstat -an | grep LISTEN | grep 11211
Das tut er: tcp 0 0 127.0.0.1:11211 0.0.0.0:\* LISTEN
3. Apache2 für das PHP Modul durchgestartet: /etc/init.d/apache2 restart
4. phpinfo angelegt und nach dem memcached Eintrag gesucht - vorhanden: memcached support enabled 5. die Application.php aus der DocumentRoot mit der aus dem VMWare Image überschrieben Jetzt dachte ich, ich müßte nur noch den Backend Cache einmal löschen und es funktionert. Leider sagt mir der Backend Aufruf: The memcache extension must be loaded for using this backend ! in Vendor/Zend/library/Zend/Cache.php on line 209 und dann kommt der Stacktrace dazu, der mir nichts sagt. Welche Schritte fehlen mir jetzt noch, um Memcached zu nutzen? Die Zeile 209 in der Cache.php ist leider nur die Zeile, die die Exception wirft.
Moin, probiere mal apt-get install php5-memcached (Also mit d) - ich glaube es gibt da 2 Extensions - habe das die Tage auch auf Squeezy installiert und hatte zuerst mit dem gleichen Problem zu kämpfen!
Da hatte ich mich leider nur vertippt. Es ist die php5-memcached installiert. Bei Version sagt mir phpinfo: Verion 1.0.2, libmemcached version 1.0.2 Bei den Sessions: Registered save handlers: files user memcached Die ini-Datei wird auch geladen: /etc/php5/cgi/conf.d/memcached.ini und die Library ist auch drin. Ich habe auch schon mal geschaut, ob der localhost in der Application.php wegen einer falschen Zuordnung evtl. durch 127.0.0.1 ausgetauscht werden muss, aber das ist nicht der Fall. Außerdem ist das in der /etc/hosts auch richtig drin. Habe ich evtl. etwas anderes vergessen oder spielt mir da evtl. die disable_functions einen Streich?: disable_functions = show_source, system, shell_exec, passthru, exec, shell, symlink, popen, proc_open
Dann ist es genau umgekehrt - apt-get install php5-memcache bitte Hatte mich da zuerst auch vertan, da gibt es wirklich 2 Extensions…
Hi, das Cache-Backend “Libmemcached” sollte auch funktionieren. Informationen dazu findest du hier: http://framework.zend.com/manual/de/zen … kends.html Ich würde aber den “TwoLevels”-Backend nutzen, da damit auch die Cache-Tags funktionieren und so einzelne Cache-Teile geleert werden könne. Beim “TwoLevels”-Backend gibt es zwei Cache-Ebenen, so können weniger gefragte Daten (z.B. die Cache-Tags) im langsamen/größeren Cache gespeichert werden und oft gefragte Dateien im schnelleren/kleinen Cache gespeichert werden. Viele Grüße Heiner
[quote=“Stefan Hamann”]Dann ist es genau umgekehrt - apt-get install php5-memcache bitte Hatte mich da zuerst auch vertan, da gibt es wirklich 2 Extensions…[/quote] Das bekomme ich nicht installiert: Die folgenden Pakete haben verletzte Abhängigkeiten: php5-memcache: Hängt ab von: php5-common (= 5.3.3-0.dotdeb.1) aber 5.3.3-5 ist installiert.
Da ist irgendeine Abhängigkeit in meiner sources.list nicht in Ordnung.
Du solltest mal die dotdeb sources entfernen - bei Squeezy kommst du ja im Moment so noch auf die aktuellen PHP-Versionen, da noch nicht final?
[quote=“Stefan Hamann”]Du solltest mal die dotdeb sources entfernen - bei Squeezy kommst du ja im Moment so noch auf die aktuellen PHP-Versionen, da noch nicht final?[/quote] Jawoll, das war’s! Entpacke php5-memcache (aus .../php5-memcache\_3.0.4-4\_amd64.deb) ... Richte php5-memcache ein (3.0.4-4) ...
Nun funktionieren Backend und Frontend. Vielen Dank! Das ganze gibt tatsächlich einen kleinen Geschwindigkeitsschub beim Laden. Ziehe ich im Firebug den ersten Verbindungsaufbau ab komme ich mit einem Force Reload (leerer Client-Cache) und gefülltem Servercache auf nur noch eine knappe Sekunde Ladezeit (mit zwei Test-Artikeln, wobei einer auf der Startseite angezeigt wird) Mannomann, bei diesem Support bekomme ich langsam ein schlechtes Gewissen, dass wir noch keine Zusatzmodule gekauft haben, aber so weit sind wir (leider) noch nicht.
Moin, das macht sich eher bei vielen Anfragen bemerkbar - sprich, wenn du die Ergebnisse z.B. mit apache bench prüfst, müsste ein deutlicherer Unterschied sichtbar werden! Welche Hardware hat dein Server eigentlich? Meine lokale Testumgebung benötigt so ca. 300 ms für die Auslieferung einer Seite, bei knapp 100 Artikeln. Also nur mal interessehalber
Mein apache Benchmark gibt mir lokal um die 165ms Durchschnitt pro Request bei 100 Requests, allerdings bei nur zwei Artikeln. Das ist allerdings eine Milchmädchenrechnung, denn hier wird nur “/” geladen. Firebug halte ich für aussagekräftiger, wenn man eben die initiale Zeit zum Verbinden abzieht, denn die ist von der DSL-Leitung und der Qualität des Providers abhängig. Was gerne auch von Testern/Firmen vergesen wird, ist die Zeit zum Übertragen und zum Aufbauen der Seite im Browser. Das macht meist 70-80% aus und da könnte Shopware mit weiteren CSS Sprites, einer minified-shopware.js und einer zusammengeführten CSS Datei auch noch einiges rausholen. Was bringt es mir, wenn ich eine Seite in 200ms ausliefern kann und der Client 5 Sekunden bis zum Übertragungsende und für den Seitenaufbau braucht? Wir nutzen übrigens einen Quad-Core mit 8GB RAM
Ich habe memcache übrigens wieder deaktiviert, weil ich damit aus mir nicht erfindlichen Gründen den Cache im Backend nicht mehr löschen konnte. Zwar wurde mir angezeigt, dass der Cache jetzt nicht mehr auf der Platte liegt und grundsätzlich hat das Ding auch funktioniert, nur hatte das Löschen des Caches keinen Effekt. Hat noch jemand dieses Problem? Muss ich evtl. außer in der Application.php noch eine weitere Änderung machen?
Hey, ich hatte das Problem selbst auch - sieht nach einem Fehler in der Zend-Cache Komponente selbst aus, wollte mir das aber noch einmal genau ansehen. Wenn ich was neues weiß, melde ich mich.
Das Cache löschen funtioniert im Backend nicht, weil dieses Backend “Memcached” keine Cache-Tags unterstützt. Diese werden dafür aber benötigt. Du kannst das Problem umgehen, in dem du das TwoLevels-Backend nutzt. Damit hast dann ein schnelles Backend für die Daten ein langsames Backend für die Cache-Tags: http://framework.zend.com/manual/de/zen … kends.html
Hilf mir doch mal bitte auf die Sprünge. Ich bin seit Ende der Unizeit ein miserabler Programmierer und habe mich mit dem Zend Framework überhaupt noch nicht auseinander gesetzt. Wie müssen die Änderungen in der Application.php (im Vergleich zur Memcache Variante aus dem VMWare Image) aussehen, damit ich den Two Level Cache nutzen kann? Poste doch mal bitte Dein File.
Hi, bevor du den Two-Levels-Cache aktviertst, solltest du den Cache einmal komplett leeren. Wenn du das nicht machst, bekommst du nacher komische Fehlermeldungen. Du solltest auch den von Memcached-Server leeren. Dafür habe dir eine kleines Tool geschrieben. (siehe unten) Hier die Config aus meiner Application.php: 'cache' =\> array( 'frontendOptions' =\> array( 'automatic\_serialization' =\> true, 'automatic\_cleaning\_factor' =\> 0, 'lifetime' =\> 3600 ), 'backend' =\> 'Two Levels', 'backendOptions' =\> array( 'slow\_backend' =\> 'File', 'slow\_backend\_options' =\> array( 'hashed\_directory\_umask' =\> 0771, 'cache\_file\_umask' =\> 0644, 'hashed\_directory\_level' =\> 2, 'cache\_dir' =\> $this-\>DocPath().'cache/database', 'file\_name\_prefix' =\> 'shopware' ), 'fast\_backend' =\> 'Memcached', 'fast\_backend\_options' =\> array( 'servers' =\> array( array( 'host' =\> 'localhost', 'port' =\> 11211, 'persistent' =\> true, 'weight' =\> 1, 'timeout' =\> 5, 'retry\_interval' =\> 15, 'status' =\> true, 'failure\_callback' =\> null ) ), 'compression' =\> false, 'compatibility' =\> false ) )
Hier der das oben genannte Tool: [code]<?php $memcache = new Memcache;
memcache->connect("localhost", 11211); if(!empty(_GET[‘action’])) { switch ($_GET[‘action’]) { case ‘flush’: var_dump($memcache->flush()); break; case ‘stats’: echo "
"; print\_r($memcache-\>getExtendedStats()); echo "
"; default: break; } } $memcache->close(); ?>flush | stats[/code] Viele Grüße Heiner
Der Hammer! Funktioniert beides tadellos. Und den Cache kann ich jetzt de facto auch im Backend löschen. Meine Messergebnisse zeigen zwar keinen Geschwindigkeitsgewinn, aber dafür werden wir wahrscheinlich nicht signifikant langsamer, wenn wir deutlich mehr als die momentan 165 Artikel im Shop haben. SUPER, HERZLICHEN DANK!
Aus der Doku zu memcached ist mir nicht klar in welche config der Eintrag
'session' =\> array( 'save\_handler' =\> 'memcached', 'save\_path' =\> "localhost:11211", ), 'backendsession' =\> array( 'save\_handler' =\> 'memcached', 'save\_path' =\> "localhost:11211", ),
muss, weil es in der config.php im webroot nichts dazu gibt.
Und unterstützt shopware sessions.redundancy also das schreiben der session auf mehrere memcached Server?
also sowas wie es auch in der PHP.ini steht:
in der memcached.ini steht:
extension=memcached.so memcached.allow\_failover=1 memcached.session\_redundancy=3
in der php.ini
session.save\_handler = memcached session.save\_path = "tcp://10.0.0.1:11211,tcp://10.0.0.2:11211"
muss ich die session.redundancy in shopware auch mit angeben wie in den ini’s?
'session' =\> array( 'save\_handler' =\> 'memcached', 'save\_path' =\> "tcp://10.0.0.1:11211,tcp://10.0.0.2:11211", 'allow\_failover' =\> "true", 'redundancy' =\> "3", // must be one more than servers ),
Am einfachsten wäre, wenn man in shopware gar nichts angeben müßte und shopware die ini Einstellungen benutzt…
Mein apache Benchmark gibt mir lokal um die 165ms Durchschnitt pro Request bei 100 Requests, allerdings bei nur zwei Artikeln. Das ist allerdings eine Milchmädchenrechnung, denn hier wird nur „/“ geladen. Firebug halte ich für aussagekräftiger, wenn man eben die initiale Zeit zum Verbinden abzieht, denn die ist von der DSL-Leitung und der Qualität des Providers abhängig.
Du kannst mit AB ja auch gezielt Seiten anfragen die aufwändiger sind. Hab neulich den Warenkorb oder gezielt einzelne Produktseiten getestet
Interessant dabei is ein Blick ins top / htop damit Du sehen kannst ob php oder mysql gerade der Flaschenhals ist.