Development

Documentation/de_DE/book/1.0/12-Caching (diff)

You must first sign up to be able to contribute.

Changes between Version 8 and Version 9 of Documentation/de_DE/book/1.0/12-Caching

Show
Ignore:
Author:
Jan.Kunzmann (IP: 84.190.19.106)
Timestamp:
03/20/08 14:05:24 (10 years ago)
Comment:

switched to 1.1 branch

Legend:

Unmodified
Added
Removed
Modified
  • Documentation/de_DE/book/1.0/12-Caching

    v8 v9  
    11'''ARBEITSENTWURF ROHÜBERSETZUNG / TRANSLATION WORKING DRAFT'''[[BR]] 
    2 Originaldokument: http://svn.symfony-project.com/doc/trunk/book/12-Caching.txt, Version 4455 vom 2007-06-27[[BR]] 
     2Originaldokument: http://svn.symfony-project.com/doc/branches/1.1/book/12-Caching.txt, Version 7789 vom 2008-03-09[[BR]] 
    33Übersetzungsfortschritt: 100%[[BR]] 
    44Übersetzung: JK[[BR]] 
    3434Für jede Anwendung eines Projekts und für jede Umgebung kann der HTML-Cachingmechanismus über die Einstellung `cache` in der Datei `settings.yml` ein- oder ausgeschaltet (Voreinstellung) werden. Listing 12-1 zeigt, wie der Cache aktiviert wird. 
    3535 
    36 Listing 12-1 - Aktivieren des Caches, in `myapp/config/settings.yml` 
     36Listing 12-1 - Aktivieren des Caches, in `frontend/config/settings.yml` 
    3737 
    3838    dev: 
    5252Aktivierung und Einstellungen des Caches sind für jede Action in einer Datei namens `cache.yml` im Verzeichnis `config/` des Moduls gespeichert. Listing 12-2 zeigt ein Beispiel. 
    5353 
    54 Listing 12-2 - Den Cache für eine Action aktivieren, in `myapp/modules/user/config/cache.yml` 
     54Listing 12-2 - Den Cache für eine Action aktivieren, in `frontend/modules/user/config/cache.yml` 
    5555 
    5656    list: 
    6363Um die Cache-Einstellungen zu testen, rufen Sie die Action in der Entwicklungs-Umgebung (`dev`) in Ihrem Browser auf. 
    6464 
    65     http://myapp.example.com/myapp_dev.php/user/list 
     65    http://myapp.example.com/frontend_dev.php/user/list 
    6666 
    6767Sie werden auf der Seite einen Rahmen um den Bereich der Action bemerkten. Beim ersten Aufruf hat der Bereich eine blaue Kopfzeile, welche anzeigt, dass die Daten nicht aus dem Cache kommen. Wenn Sie die Seite erneut laden, ist die Kopfzeile des Bereichs gelb, was bedeutet, dass die Daten jetzt aus dem Cache kommen (mit einer merkbar schnelleren Antwortzeit). Später in diesem Kapitel werden Sie noch mehr darüber lernen, wie Sie das Caching testen und überwachen. 
    7474Um Ihre `cache.yml` etwas zu strukturieren, können Sie die Einstellungen, die auf alle Actions eines Moduls zutreffen, unterhalb des Schlüssels `all:` gruppieren, wie ebenfalls in Listing 12-3 zu sehen. 
    7575 
    76 Listing 12-3 - Eine vollständige `cache.yml`-Datei, in `myapp/modules/user/config/cache.yml` 
     76Listing 12-3 - Eine vollständige `cache.yml`-Datei, in `frontend/modules/user/config/cache.yml` 
    7777 
    7878    list: 
    110110Listing 12-4 zeigt, wie Sie die Datei `cache.yml` bearbeiten müssen, um den Cache für die Datei `_mein_partial.php` des Modules `user` einzuschalten. Beachten Sie, dass die Einstellung `with_layout` in diesem Fall sinnlos ist. 
    111111 
    112 Listing 12-4 - Cachen eines Partials, in `myapp/modules/user/config/cache.yml` 
     112Listing 12-4 - Cachen eines Partials, in `frontend/modules/user/config/cache.yml` 
    113113 
    114114    _mein_partial: 
    155155Nehmen wir an, Sie haben eine Liste mit Benutzern, und dazu einen Link auf den zuletzt aufgerufenen Benutzer, wobei diese Information dynamisch ist. Der Helper `cache()` legt die Teile des Templates fest, die in den Cache gehen können. Listing 12-5 zeigt die syntaktischen Details. 
    156156 
    157 Listing 12-5 - Verwendung des `cache()`-Helfers, in `myapp/modules/user/templates/listSuccess.php` 
     157Listing 12-5 - Verwendung des `cache()`-Helfers, in `frontend/modules/user/templates/listSuccess.php` 
    158158 
    159159    [php] 
    199199Warum sollten Sie den Cache überhaupt dynamisch einstellen können? Ein gutes Beispiel ist eine Seite, die für authentifizierte Benutzer anders aussieht als für unangemeldete, deren URL jedoch die gleiche bleibt. Stellen Sie sich z.B. eine Seite `article/show` mit einem Ratingsystem für Artikel vor. Das Ratingsystem ist für unangemeldete Benutzer nicht aktiviert, statt dessen führen für sie die Links auf ein Loginformular. Diese Version der Seite kann gecachet werden. Bei angemeldeten Benutzern löst der Klick auf einen Ratinglink einen POST-Request aus und erzeugt ein neues Rating. Dafür muss der Cache abgeschaltet sein, so dass Symfony die Seite dynamisch aufbaut. 
    200200 
    201 Der richtige Ort, um diese Cache-Einstellungen zu definieren, ist ein Filter, der vor dem `sfCacheFilter` ausgeführt wird. Tatsächlich ist der Cache nur ein Symfony-Filter, wie auch der Web-Debug-Toolbar und die Sicherheitsfunktionen. Um den Cache der Seite `article/show` nur zu aktivieren, wenn der User noch unauthentifiziert ist, erzeugen Sie einen `conditionalCacheFilter` im `lib/`-Verzeichnis Ihrer Anwendung, wie in Listing 12-6 gezeigt. 
    202  
    203 Listing 12-6 - Dynamische Konfigurieration des Caches mit PHP, in `myapp/lib/conditionalCacheFilter.class.php` 
     201Der richtige Ort, um diese Cache-Einstellungen zu definieren, ist ein Filter, der vor dem `sfCacheFilter` ausgeführt wird. Tatsächlich ist der Cache nur ein Symfony-Filter, wie auch die Sicherheitsfunktionen. Um den Cache der Seite `article/show` nur zu aktivieren, wenn der User noch unauthentifiziert ist, erzeugen Sie einen `conditionalCacheFilter` im `lib/`-Verzeichnis Ihrer Anwendung, wie in Listing 12-6 gezeigt. 
     202 
     203Listing 12-6 - Dynamische Konfigurieration des Caches mit PHP, in `frontend/lib/conditionalCacheFilter.class.php` 
    204204 
    205205    [php] 
    213213          foreach ($this->getParameter('pages') as $page) 
    214214          { 
    215             $context->getViewCacheManager()->addCache($page['module'], $page['action'],array('lifeTime' => 86400)); 
     215            $context->getViewCacheManager()->addCache($page['module'], $page['action'], array('lifeTime' => 86400)); 
    216216          } 
    217217        } 
    224224Sie müssen diesen Filter in der Datei `filters.yml` vor dem `sfCacheFilter` registrieren, wie in Listing 12-7 zu sehen. 
    225225 
    226 Listing 12-7 - Registrierung Ihres eigenen Filters, in `myapp/config/filters.yml` 
     226Listing 12-7 - Registrierung Ihres eigenen Filters, in `frontend/config/filters.yml` 
    227227 
    228228    ... 
    251251>Alterantive Speicherorte für den Cache 
    252252> 
    253 >Standardmäßig speichert das Cachesystem von Symfony seine Informationen in Dateien auf der Festplatte des Webservers. Möglicherweise wollen Sie die Daten aber auch im Hauptspeicher ablegen (z.B. mittels memcache), oder in einer Datenbank (vor allem, wenn Sie von mehreren Servern auf den Cache zugreifen oder die Entfernung von Daten beschleunigen wollen). Symfonys Standard-Cachesystem können Sie einfach ändern, da die Klasse, die der View-Cache-Manager von Symfony verwendet, in `factories.yml` festgelegt ist. 
     253>Standardmäßig speichert das Cachesystem von Symfony seine Informationen in Dateien auf der Festplatte des Webservers. Möglicherweise wollen Sie die Daten aber auch im Hauptspeicher ablegen (z.B. mittels [memcached](http://www.danga.com/memcached/)), oder in einer Datenbank (vor allem, wenn Sie von mehreren Servern auf den Cache zugreifen oder die Entfernung von Daten beschleunigen wollen). Symfonys Standard-Cachesystem können Sie einfach ändern, da die Klasse, die der View-Cache-Manager von Symfony verwendet, in `factories.yml` festgelegt ist. 
    254254> 
    255255>Standard-Factory für die Speicherklasse des View-Caches ist `sfFileCache`: 
    261261>           cacheDir:                %SF_TEMPLATE_CACHE_DIR% 
    262262> 
    263 >Sie können in der Angabe `class` Ihre eigene Speicherklasse angeben oder eine der von Symfony bereitgestellten Alternativen (z.B. `sfSQLiteCache`). Die Parameter unterhalb des Schlüssels `param` werden Ihrer Klasse als assioziatives Array durch die Methode `initialize()` übergeben. Jede solche Speicherklasse muss alle Methoden abstrakten Methoden aus `sfCache` implementieren. In der API-Dokumentation ([http://www. symfony-project.com/api/symfony.html](http://www. symfony-project.com/api/symfony.html)) finden Sie weitere Informationen über dieses Thema. 
     263>Sie können in der Angabe `class` Ihre eigene Speicherklasse angeben oder eine der von Symfony bereitgestellten Alternativen (z.B. `sfAPCCache`, `sfEAcceleratorCache`, `sfMemcacheCache`, `sfSQLiteCache` oder `sfXCacheCache`). Die Parameter unterhalb des Schlüssels `param` werden dem Konstruktor Ihrer Klasse als assioziatives Array übergeben. Jede solche Speicherklasse muss alle Methoden abstrakten Methoden aus `sfCache` implementieren. In der API-Dokumentation ([http://www.symfony-project.com/api/symfony.html](http://www.symfony-project.com/api/symfony.html)) finden Sie weitere Informationen über dieses Thema. 
    264264 
    265265### Verwendung des superschnellen Caches 
    268268 
    269269Sie können dies dann manuell Seite für Seite mit einem einfachen Kommandozeilenaufruf durchführen: 
    270 You can do this by hand, page by page, with a simple command-line call: 
    271270 
    272271    > curl http://myapp.example.com/user/list.html > web/user/list.html 
    302301    > symfony cc 
    303302 
    304     // Löscht nur den Cache der Anwendung myapp 
    305     > symfony clear-cache myapp 
    306  
    307     // Löscht nur den HTML-Cache der Anwendung myapp 
    308     > symfony clear-cache myapp template 
    309  
    310     // Löscht nur den Konfigurationscache der Anwendung myapp 
    311     > symfony clear-cache myapp config 
     303    // Löscht nur den Cache der Anwendung frontend 
     304    > symfony clear-cache frontend 
     305 
     306    // Löscht nur den HTML-Cache der Anwendung frontend 
     307    > symfony clear-cache frontend template 
     308 
     309    // Löscht nur den Konfigurationscache der Anwendung frontend 
     310    > symfony clear-cache frontend config 
    312311 
    313312### Löschen von bestimmten Teilen des Caches 
    337336    } 
    338337 
    339 Partials, Komponenten und Komponentenslots aus dem Cache zu löschen ist etwas schwieriger. Da Sie ihnen jede Art von Parametern übergeben können (auch Objekte), ist es fast unmöglich, die gecachete Version zu ermitteln. Richten wir unseren Blick auf die Partials, denn die anderen Templatekomponenten verhalten sich analog. Symfony identifiziert ein gecachetes Partial über einen speziellen Prefix (`sf_cache_partial`), den Namen des Moduls, den Namen des Partials und ein Hash aus allen Parametern des Aufrufs, wie folgt: 
     338Partials, Komponenten und Komponentenslots aus dem Cache zu löschen ist etwas schwieriger. Da Sie ihnen jede Art von Parametern übergeben können (auch Objekte), ist es fast unmöglich, hinterher die gecachete Version zu ermitteln. Richten wir unseren Blick auf die Partials, denn die anderen Templatekomponenten verhalten sich analog. Symfony identifiziert ein gecachetes Partial über einen speziellen Prefix (`sf_cache_partial`), den Namen des Moduls, den Namen des Partials und ein Hash aus allen Parametern des Aufrufs, wie folgt: 
    340339 
    341340    [php] 
    344343 
    345344    // wird im Cache so identifiziert: 
    346     /sf_cache_partial/user/_mein_partial/sf_cache_key/bf41dd9c84d59f3574a5da244626dcc8 
     345    @sf_cache_partial?module=user&action=_mein_partial&sf_cache_key=bf41dd9c84d59f3574a5da244626dcc8 
    347346 
    348347In der Theorie können Sie ein gecachetes Partial mit der Methode `remove()` entfernen, wenn Sie die Werte des Parameterhashs kennen, der es identifiziert; dies jedoch ist nicht praktikabel. Wenn Sie jedoch beim Aufruf von `include_partial()` einen Parameter namens `sf_cache_key` übergeben, können Sie das Partial im Cache über einen Ihnen bekannten Wert identifizieren. Wie Sie in Listing 12-10 sehen können, wird das Entfernen eines einzelnen gecacheten Partials - z.B. um ein Partial eines aktualisierten Objekts `User` aus dem Cache zu löschen - ganz einfach. 
    357356 
    358357    // wird im Cache so identifiziert: 
    359     /sf_cache_partial/user/_mein_partial/sf_cache_key/12 
    360  
    361     // _mein_partial für einen bestimmten User aus dem Cache löschen mit $cacheManager->remove('@sf_cache_partial?module=user&action=_mein_partial&sf_cache_key='.$user->getId()); 
    362  
    363 Sie können diese Methode allerdings nicht verwenden, um alle Vorkommen eines Partials im Cache zu löschen. Wie Sie dies bewerkstelligen, lernen Sie im Abschnitt "Manuelles Löschen des Caches" weiter unten in diesem Kapitel. 
     358    @sf_cache_partial?module=user&action=_mein_partial&sf_cache_key=12 
     359 
     360    // _mein_partial für einen bestimmten User aus dem Cache löschen mit 
     361    $cacheManager->remove('@sf_cache_partial?module=user&action=_mein_partial&sf_cache_key='.$user->getId()); 
    364362 
    365363Um Templatefragmente zu löschen, können Sie die gleiche Methode `remove()` verwenden. Der Schlüssel, der das Fragment im Cache identifiziert, ist genauso wie oben aus dem Prefix `sf_cache_partial`, dem Modulnamen, dem Namen der Action und dem `sf_cache_key` (also dem eindeutigen Namen des Cachefragments, der dem Helper `cache()` übergeben wird). Listing 12-11 zeigt ein Beispiel. 
    375373 
    376374    // wird im Cache so identifiziert 
    377     /sf_cache_partial/user/list/sf_cache_key/users 
     375    @sf_cache_partial?module=user&action=list&sf_cache_key=users 
    378376 
    379377    // Löschen mit 
    403401>Und wenn Sie Ihr Gehirn nicht mit allzu tiefgehender Analyse zermartern wollen, können Sie einfach jedes Mal den gesamten Cache leeren, wenn Sie Daten in der Datenbank aktualisiert haben . . . 
    404402 
    405 ### Verzeichnisstruktur des Caches 
    406  
    407 Das Verzeichnis `cache/` in Ihrer Anwendung hat folgende Struktur: 
    408  
    409     cache/                 # sf_root_cache_dir 
    410       [APP_NAME]/          # sf_base_cache_dir 
    411         [ENV_NAME]/        # sf_cache_dir 
    412           config/          # sf_config_cache_dir 
    413           i18n/            # sf_i18n_cache_dir 
    414           modules/         # sf_module_cache_dir 
    415           template/        # sf_template_cache_dir 
    416             [HOST_NAME]/ 
    417               all/ 
    418  
    419 Gecachete Templates werden unterhalb des Verzeichnisses `[HOST_NAME]` gespeichert (wobei aus Gründen der Kompatibilität die Punkte durch Unterstriche ersetzt werden), in einer Verzeichnisstruktur, die mit der URL korrelieren. So wird z.B. der Templatecache für die Seite: 
    420  
    421     http://www.myapp.com/user/show/id/12 
    422  
    423 hier gespeichert: 
    424  
    425     cache/myapp/prod/template/www_myapp_com/all/user/show/id/12.cache 
    426  
    427 Sie sollten Dateipfade nie direkt in Ihren Code schreiben. Stattdessen sollten Sie besser Pfadkonstanten verwenden. Wenn Sie beispielsweise den absoluten Pfad zum Verzeichnis `template/` der aktuellen Anwendung in der aktuellen Umgebung ermitteln wollen, verwenden Sie `sfConfig::get('sf_template_cache_dir')`. 
    428  
    429 Es wird Ihnen beim manuellen Löschen des Caches helfen, diese Verzeichnisstruktur zu kennen. 
    430  
    431 ### Manuelles Löschen des Caches 
    432  
    433 Es stellt ein Problem dar, den Cache anwendungsübergreifend zu löschen. Wenn ein Administrator beispielsweise einen Datensatz in der Tabelle `user` über die Anwendung `backend` ändert, müssen auch alle von diesem Benutzer abhänmgigen Actions im `frontend` aus dem Cache entfernt werden. Die Methode `remove()` erwartet eine interne URI, aber Anwendungen kennen nicht die Routingregeln anderer Anwendungen (sie sind voneinander komplett isoliert). Deshalb können Sie die Methode `remove()` nicht verwenden, um den Cache einer anderen Anwendung zu löschen. 
    434  
    435 Die Lösung ist, die Dateien basierend auf dem Pfad manuell aus dem Verzeichnis `cache/` zu löschen. Wenn z.B. das `backend` den Cache der Actions `user/show` im `frontend` für den User mit der `id` `12` löschen möchte, könnten Sie folgendes schreiben: 
    436  
    437     [php] 
    438     $sf_root_cache_dir = sfConfig::get('sf_root_cache_dir'); 
    439     $cache_dir = $sf_root_cache_dir.'/frontend/prod/template/www_myapp_com/all'; 
    440     unlink($cache_dir.'/user/show/id/12.cache'); 
    441  
    442 Dies ist allerdings nicht sehr zufriedenstellend. Das Kommando löscht nur den Cache aus der aktuellen Umgebung, und es zwingt Sie, den Namen der Umgebung und den Hostnamen in den Dateipfad zu schreiben. Um diese Limitierung zu umgehen, können Sie die Methode `sfToolkit::clearGlob()` verwenden. Sie nimmt als Parameter ein Dateimuster entgegen und verarbeitet dabei Platzhalter (Wildcards). Den Cache aus dem vorherigen Beispiel können Sie, ohne Rücksicht auf Host und Umgebung, so löschen: 
    443  
    444     [php] 
    445     $cache_dir = $sf_root_cache_dir.'/frontend/*/template/*/all'; 
    446     sfToolkit::clearGlob($cache_dir.'/user/show/id/12.cache'); 
    447  
    448 Diese Methode ist ebenfalls von großem Nutzen. wenn Sie eine gecachete Action unabhängig von bestimmten Parametern löschen wollen. Beu einer mehrsprachigen Anwendung könnten Sie sich beispielsweise dafür entschieden haben, das Sprachkürzel mit in die URLs aufzunehmen. Ein Link auf ein Benutzerprofil sähe damit so aus: 
     403### Mehrere Teile des Caches auf einmal löschen (Neu in Symfony 1.1) 
     404 
     405Die Methode `remove()` nimmt Schlüssel mit Platzhaltern entgegen. Dies ermöglicht es Ihnen, mehrere Teile des Caches mit einem einzigen Aufruf zu löschen. Sie können z.B. folgendes tun: 
     406 
     407    [php] 
     408    $cacheManager->remove('user/show?id=*');    // Entfernt die Datensätze aller Benutzer 
     409 
     410Ein weiteres gutes Beispiel ist eine Anwendung, die mehrere verschiedene Sprachen anzeigt, wobei das Sprachkürzel in den URLs auftaucht. Die URL einer Seite mit einem Benutzerprofil sollte in etwa so aussehen: 
    449411 
    450412    http://www.myapp.com/en/user/show/id/12 
    451413 
    452 Wenn Sie nun das gecachete Profil des Users mit `id` `12` in allen Sprachen löschen wollen, können Sie einfach dies schreiben: 
    453  
    454     [php] 
    455     sfToolkit::clearGlob($cache_dir.'/*/user/show/id/12.cache'); 
     414Um das gecachete Profil eines Users mit der `id` `12` in allen Sprachen zu löschen, können Sie einfach folgendes aufrufen: 
     415 
     416    [php] 
     417    $cache->remove('user/show?sf_culture=*&id=12'); 
     418 
     419Dies funktioniert auch bei Partials: 
     420 
     421    [php] 
     422    $cacheManager->remove('@sf_cache_partial?module=user&action=_my_partial&sf_cache_key=*');    // Löscht den Cache für alle Schlüssel 
     423 
     424Die Methode `remove()` nimmt noch zwei weitere Parameter entgegen, die Ihnen erlaubt, für welche Hosts und Vary-Header der Cache zu löschen ist. Dies kann notwendig sein, da Symfony für jeden Host und jeden Vary-Header einen eigenen Cache vorhält, so dass zwei Anwendungen, die auf der gleichen Codebasis arbeiten, aber über unterschiedliche Hostnamen aufgerufen werden, auch verschiedene Caches verwenden. Dies kann z.B. dann von großem Nutzen sein, wenn eine Anwendung auch die Subdomain als Abfrageparameter verarbeitet (wie `http://php.askeet.com` und `http://life.askeet.com`). Wenn Sie die beiden letzten Parameter nicht angeben, löscht Symfony den Cache für den aktuellen Host und für den Vary-Header `all`. Wenn Sie den Cache für einen anderen Host löschen wollen, rufen Sie `remove()` wie folgt auf: 
     425 
     426    [php] 
     427    $cacheManager->remove('user/show?id=*');                     // Entfernt die Datensätze aller User für den aktuellen Host 
     428    $cacheManager->remove('user/show?id=*', 'life.askeet.com');  // Entfernt die Datensätze aller User für den HostRemove life.askeet.com 
     429    $cacheManager->remove('user/show?id=*', '*');                // Entfernt die Datensätze aller User für alle Hosts 
     430 
     431Die Methode `remove()` funktioniert bei allen Caching-Strategien, die Sie in `factories.yml` angeben können (nicht nur bei `sfFileCache`, sondern auch bei `sfAPCCache`, `sfEAcceleratorCache`, `sfMemcacheCache`, `sfSQLiteCache` und `sfXCacheCache`). 
     432 
     433### Löschen des Caches über Anwendungsgrenzen hinweg (Neu in symfony 1.1) 
     434 
     435Das Löschen des Caches über die Grenzen der Anwendungen hinweg kann ein Problem darstellen. Wenn beispielsweise der Administrator einen Datensatz der Tabelle `user` in der `backend`-Anwendung ändert, müssen alle Actions in der `frontend`-Anwendung, die von diesem User abhängen, aus dem Cache gelöscht werden. Allerdings kennt der View-Cache-Manager der `backend`-Anwendung die Routingregeln der `frontend`-Anwendung nicht (die Anwendungen sind voneinander völlig isoliert. Folglich können Sie im Backend nicht einfach folgendes schreiben: 
     436 
     437    [php] 
     438    $cacheManager = sfContext::getInstance()->getViewCacheManager(); // Viewmanager für das Backend ermitteln 
     439    $cacheManager->remove('user/show?id=12');                        // Dieses Muster wird nicht gefunden, da das Template im Frontend gecachet ist 
     440 
     441Die Lösung ist, das `sfCache`-Objekt von Hand mit den Einstellungen des Frontend-Cachemanagers zu initialisieren. Praktischerweise stellen alle Cache-Klassen in Symfony eine Methode namens `removePattern()` zur Verfügung, die das gleiche match wie `remove()` im View-Cache-Manager. 
     442 
     443Wenn also die `backend`-Anwendung den Cache der Action `user/show` im Frontend für den User mit der `id` `12` löschen muss, können Sie folgendes schreiben: 
     444 
     445    [php] 
     446    $frontend_cache_dir = sfConfig::get('sf_root_cache_dir') . DIRECTORY_SEPARATOR . 'frontend' . DIRECTORY_SEPARATOR . SF_ENV . DIRECTORY_SEPARATOR . 'template'; 
     447    $cache = new sfFileCache(array('cache_dir' => $frontend_cache_dir)); // Verwende die Einstellungen, die in der factories.yml des Frontends definiert sind 
     448    $cache->removePattern('user/show?id=12'); 
     449 
     450Für andere Caching-Strategien müssen Sie nur die Initialisierung des Cache-Objekts ändern, aber der Löschprozess bleibt der gleiche: 
     451 
     452    [php] 
     453    $cache = new sfMemcacheCache(array('prefix' => 'frontend')); 
     454    $cache->removePattern('user/show?id=12'); 
    456455 
    457456Den Cache testen und überwachen 
    458457------------------------------- 
    459458 
    460 Wenn HTML-Caching nicht richtig verarbeitet wird, kann das zu Inkoherenzen der angezeigten Daten führen. Wenn Sie den Cache für ein Element deaktivieren, sollten Sie es gründlich testen und die Ausführung überwachen, um es zu tunen. 
    461 <!-- Unklare Formulierung: HTML caching, if not properly handled, can create incoherence in displayed data. Each time you disable the cache for an element, you should test it thoroughly and monitor the execution boost to tweak it. --> 
     459Wenn mit dem HTML-Caching nicht richtig umgegangen wird, kann das zu Inkoherenzen der angezeigten Daten führen. Wenn Sie den Cache für ein Element deaktivieren, sollten Sie es gründlich testen und die Ausführung überwachen, um es zu tunen. <!-- Unklare Formulierung: Each time you disable the cache for an element, you should test it thoroughly and monitor the execution boost to tweak it. --> 
    462460 
    463461### Erstellen einer Staging-Umgebung 
    467465Zur Einrichtung bearbeiten Sie die Datei `settings.yml` Ihrer Anwendung und fügen am Beginn die Zeilen aus Listing 12-12 ein. 
    468466 
    469 Listing 12-12 - Einstellungen für die Umgebung `staging`, in `myapp/config/settings.yml` 
     467Listing 12-12 - Einstellungen für die Umgebung `staging`, in `frontend/config/settings.yml` 
    470468 
    471469    staging: 
    474472        cache:      on 
    475473 
    476 Zusätzlich erzeugen Sie einen neuen Frontcontroller, indem Sie den Produktions-Controller (wahrscheinlich `myproject/web/index.php`) in eine neue Datei namens `myapp_staging.php` kopieren. Bearbeiten Sie und ändern Sie die Werte `SF_ENVIRONMENT` und `SF_DEBUG` wie folgt: 
     474Zusätzlich erzeugen Sie einen neuen Frontcontroller, indem Sie den Produktions-Controller (wahrscheinlich `myproject/web/index.php`) in eine neue Datei namens `frontend_staging.php` kopieren. Bearbeiten Sie und ändern Sie die Werte `SF_ENVIRONMENT` und `SF_DEBUG` wie folgt: 
    477475 
    478476    [php] 
    482480Das war es schon - Sie haben eine neue Umgebung erstellt. Um sie zu verwenden, geben Sie den Namen des Frontcontrollers nach dem Domainnamen an: 
    483481 
    484     http://myapp.example.com/myapp_staging.php/user/list 
     482    http://myapp.example.com/frontend_staging.php/user/list 
    485483 
    486484>**TIP** 
    487 >Statt einen bestehenden Frontcontroller zu kopieren, können Sie über den Kommandozeilenbefehl `symfony` einfach einen neuen erzeugen. Wenn Sie z.B. für eine Umgebung `staging` in der Anwendung `myapp` einen Frontcontroller namens `myapp_staging.php` erzeugen wollen, bei der `SF_DEBUG` auf `true` gesetzt ist, rufen Sie einfach folgendes auf: `symfony init-controller myapp staging myapp_staging true`. 
     485>Statt einen bestehenden Frontcontroller zu kopieren, können Sie über den Kommandozeilenbefehl `symfony` einfach einen neuen erzeugen. Wenn Sie z.B. für eine Umgebung `staging` in der Anwendung `frontend` einen Frontcontroller namens `frontend_staging.php` erzeugen wollen, bei der `SF_DEBUG` auf `true` gesetzt ist, rufen Sie einfach folgendes auf: `symfony init-controller frontend staging frontend_staging true`. 
    488486 
    489487### Überwachen der Performance 
    530528Wenn ETag aktiviert ist, fügt der Webserver einen speziellen Header in die Antwort ein, die eine Signatur der Antwort selbst darstellt. 
    531529 
    532     ETag: 1A2Z3E4R5T6Y7U 
     530    ETag: "1A2Z3E4R5T6Y7U" 
    533531 
    534532Der Browser speichert diese Signatur und sendet sie beim nächsten Request auf die gleiche Seite mit. Wenn die neue Signatur zeigt, dass die Seite sich seit dem vorherigen Request nicht verändert hat, sendet der Server keine Antwort zurück. Stattdessen schickt er nur einen Header `304: Not modified` (dt.: "Nicht verändert"). Dies spart CPU-Zeit (z.B. wenn Ausgabekompression mit gzip aktiviert ist) und Bandbreite (Seitentransfer) auf der Serverseite, sowie Zeit (für den Seitentransfer) auf der Seite des Clients. Im Großen und Ganzen werden Seiten mit ETag aus dem Cache noch schneller geladen als solche ohne.