• Jeder User im Forum verpflichtet sich zur Akzeptanz und zur Einhaltung dieser Regeln:
    1. Umgangston
      Ein angemessener höflicher Umgangston, ohne Beleidigungen, Beschimpfungen und aggressive Postings ist für jedes Mitglied Pflicht.
    2. Beiträge
      Jedes Mitglied sollte sich bemühen nur sinnvolle Beiträge zum Thema zu posten. Dabei ist unbedingt vorher zu prüfen, ob das Thema vorher schon einmal diskutiert wurde und daher fortgesetzt werden kann
      • Suchfunktion benutzen!
      • offizielle Doku lesen!
    3. Haftung
      Jeder Beitragsersteller übernimmt die alleinige Verantwortung seiner Inhalte.
    4. Werbung
      Wir erlauben keine Beiträge, Signaturen, Private Nachrichten oder eMails an Benutzer, die Werbung enthalten. Ausgenommen
      sind Stellengesuche /-angebote, welche ausschließlich im Forum "Stellengesuche" veröffentlicht werden dürfen.
    5. Verstöße
      Regelwidrige Beiträge sollten dem Team gemeldet werden. Nach deren Überprüfung werden wir schnellstmöglich
      entsprechend handeln.
    6. Authorität
      Den Anweisungen der Team-Mitglieder (Administratoren und Moderatoren) sind in diesem Forum Folge zu leisten.
      Bei Fragen oder Beschwerden bitte an diese wenden.
    Wir möchten Euch darauf aufmerksam machen, dass es bei Verstößen gegen einen oder mehreren der oben genannten
    Punkte dem Team frei steht entsprechend zu handeln. Dies kann z.B. das Löschen eines Beitrags, das Ausschliessen bzw.
    Sperren von Mitgliedern oder aber lediglich eine Verwarnung sein.

    In diesem Zusammenhang sollte erwähnt werden, dass das Forum automatisch die IP-Adresse jedes Beitrag-Erstellers
    speichert. Bei schweren Vergehen, behalten wir es uns vor, die IP-Adresse zur Strafverfolgung weiterzugeben.
  • Willkommen im Zend Framework Forum

    ZF1 Zend Framework 1 + ZF2 Zend Framework 2

    Das Zend Framework Forum ist seit 2006 die erste Anlaufstelle für Zend Framework Entwickler in Deutschland. Mit über 70.000 Beiträgen und einer steigenden Nutzerzahl bietet das Forum hilfreiche Themen und ZF-Tutorials für professionelle Entwickler, fortgeschrittene Programmierer sowie Zend Framework Einsteiger.
    Wenn dies Dein erster Besuch in der Zend Framework Community ist, lies bitte zuerst die Hilfe - FAQ durch. Du musst Dich registrieren, bevor Du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um die Registrierung zu starten. Du kannst auch jetzt schon Beiträge lesen. Hier im Forum findest Du die Zend Framework Hilfe, die Du suchst!

    Grüße an alle Zend Framework Entwickler. Das Team vom Zend Framework Forum!

    Drupal Agentur

Zend Cache 2.0

mabe

New member
Hi Leute,

ich weiß, ich habe schon einen Thread zum Cache Refactoring, aber da das Proposal eh nicht mehr in die 1.x-Serie einfließt und für ZF 2.0 durch den BC-Break um einiges mehr Möglichkeiten offen stehen wollte ich euch zu ein paar recht speziellen Funktionsweisen was Fragen:

1. finden bestimmter Daten im Cache:
Aktuell (ZF1.x):
PHP:
$cache->getIds();
$cache->getIdsMatchingTags()
// usw.
Das ist so sehr umständlich ich hätte dafür 2 Varianten´, um das zu vereinfachen:

1.1 - Mit Flags
PHP:
$cache->find(Zend\Cache::MATCH_ALL, $options);
// Flags:
// Zend\Cache::MATCH_ACTIVE      - keine abgelaufenen Daten
// Zend\Cache::MATCH_EXPIRED     - nur abgelaufene Daten
// Zend\Cache::MATCH_ALL         - alle Daten
// Zend\Cache::MATCH_TAGS_OR     - suchen nach Tags mit "or"-Verknüpfung
// Zend\Cache::MATCH_TAGS_AND    - suchen nach Tags mit "and"-Verknüpfung
// ...
- schnell
- relativ undurchsichtig für Benutzer
- die Tags müssen im $options-Array angegeben werden

1.2: ala SQL:
PHP:
 $cache->find("SELECT key, value FROM cache");
$cache->find("SELECT key, value FROM cache, tag
                     WHERE cache.key = tag.key
                     AND tag.value = 'tag1' OR tag.value = 'tag2'");
- sehr Aufwändig
- bremst "find" aus
- benutzerfreundlich ?


2. Die zweite Frage bezieht sich auf das Durchlaufen der gefundenen Daten mittels find:
(Welche Daten in $data zur Verfügung stehen hängt von der Selektierung ab)

2.1 Mittels Array-Rückgabe:
PHP:
$dataArr = $cache->find();
foreach($dataArr as $data) {
    echo $data['key'];
    echo $data['value'];
    echo $data['mtime'];
    // ...
}
- sehr einfach Strukturiert
- extrem hoher Speicheraufwand bei großen Caches

2.2: Mittels fetch / fetchAll
PHP:
$cache->find();
while ( ($data = $cache->fetch()) ) {
    echo $data['key'];
    echo $data['value'];
     echo $data['mtime'];
     // ...
}

// or

$cache->find();
foreach($cache->fetchAll() as $data) {
    echo $data['key'];
    echo $data['value'];
    echo $data['mtime'];
    // ...
}
- minimiert Speicheraufwand
- man muss fetch / fetchAll aufrufen
- wird nicht von jedem Backend unterstützt und müsste dann virtuell nachgebeut werden, also intern alles in ein Array.


Wäre echt nett, wenn Ihr eure Meinung(en) dazu äußert.
Achso, das Proposal ist hier, aber noch im Auf- / Umbau:
http://framework.zend.com/wiki/display/ZFPROP/Zend+Cache+2.0+-+Marc+Bennewitz
 

DennisBecker

Super-Moderator
Ich benutze nur load(), save() und ab und zu mal remove() und fand das eigentlich soweit ok :)

Diesen Ansatz aus der Datenbank-Logik finde ich da echt ungeeignet, da dadurch meiner Meinung nach nicht wirlich klar abgegrenzt wird, was der Cache wirklich machen soll. Schön finde ich natürlich, dass Features eines Caches dann in PHP implementiert werden um es anzugleichen, nur muss dann ganz deutlich im Manual stehen, dass diese Methode rein PHP ist und dadurch langsam(er) ist als wenn man einen anderen Cache im Backend nutzen würde.
 

KingCrunch

New member
\sign
Mehr sollte ein Cache meines Erachtens auch nicht können, denn irgendwann gehts dann in Richtung Document-Storage ("Depot" oder so), was auch gut und gerne eine eigene Komponente verdient hätte.
 

mabe

New member
save / load / remove bzw. bei mir get[Multi] / set[Multi] / remove[Multi] sind für einen Cache logischerweise die wichtigsten Features ;)

Komplizierter wird es aber schon wenn Tags genutzt werden sollen: Wenn es das Backend nicht unterstützt muss es eine Möglichkeit geben die gespeicherten Items zu durchlaufen. Oder es wird eine Art Index für die Tags gespeichert, dieser müsste aber bei jedem speichern mit bearbeitet werden.

(Die clear-Funktion ist eigentlich auch direkt darauf aufgebaut, solange nicht ALLE Daten gelöscht werden sollen.)

Zudem wird dieses Durchlaufen komplett unterschiedlich bis gar nicht von den Backends unterstützt.
apc_cache_info (alles als Array) oder APCIterator
libmemcached: memcached_dump (fehlt allerdings im ext/memcached)
file: DirectoryIterator / glob
-> Die Idee dahinter war jetzt, dass durchs Aufrufen von fetch pro Item der Cache nur einmal durchlaufen werden muss und immer nur die aktuelle Position gelesen wird, was wiederum den Speicherverbrauch erheblich senken sonnte und z.B. bei entfernten Speichersystemen (memcached) die Wartezeit drastisch reduzieren kann.
-> Wichtig ist bei der Variante auch, dass man angeben kann, welche Information jedes Eintrags gelesen werden sollten. Wenn man nur den Schlüssel bracht muss nichts zusätzliches ausgelesen/Übertragen werden und wenn man jetzt zusätzlich zum Value noch Informationen benötigt wie mtime o.ä. muss man das nicht nochmal extra raussuchen.

-> Die Variante mit dem SQL war bis jetzt auch nichts weiter als eine Idee, um das ganze für den nicht so versierten Nutzer etwas verständlicher zu machen.

Mehr sollte ein Cache meines Erachtens auch nicht können, denn irgendwann gehts dann in Richtung Document-Storage ("Depot" oder so), was auch gut und gerne eine eigene Komponente verdient hätte.
-> Stimme ich dir zu. Nur ab wann ist eine (Document-)Storage ein Cache-Storage ?
-> Ist es nicht eher so, dass jedes Speichersystem für Caching verwendet werden könnte. Also geht es eigentlich nur noch darum, wo / wie die Daten sichtbar sind, und wie schnell gespeichert / gelesen werden kann.
-> Der Cache sollte meines erachtens alles mitbringen, was speziell zur Speicherung von Caches benötigt wird bzw. was ihn sicherer / schneller .... macht.
 
Oben