Michał Durys

Dzisiaj o odkrywaniu Ameryki w konserwie. Właśnie takie miałem wrażenie, gdy dłubiąc w projekcie trafiłem na rozdział na temat cache w dokumentacji Doctrine. Wcześniej tam nie trafiłem, bo całe keszowanie robiłem w Symfony – wszak do pamięci podręcznej najlepiej wrzucać efekt końcowy. Dodatkowo w dokumentacji Symfony nie rzuciło mi się w oczy nic na temat cacheowania w Doctrine.

Nie zamierzam streszczać dokumentacji Doctrine. W kontekście tej notki ważne jest, że Doctrine może zapamiętywać w cache dwa rodzaje danych:

• skompilowane zapytania
• wyniki zapytań

Dzięki zapamiętywaniu zapytań czasochłonny proces parsowania zapytania i budowania docelowej SQL-ki jest wykonywany tylko raz, kolejne wywołania będą korzystać z danych zapamiętanych w pamięci podręcznej. Problem aktualności danych w cache nie istnieje ponieważ zmiana zapytania spowoduje automatyczne wygenerowanie nowych danych. Korzyści są niebagatelne, użycie proste jak konstrukcja cepa, a problemów nie ma. Dlatego zgodnie z dokumentacją i zdrowym rozsądkiem, pamięć podręczna zapytań powinna być zawsze włączona, nawet w środowisku testowym.

Włączenie cache dla Doctrine w projekcie Symfony jest banalne i sprowadza się do dodania króciutkiej metody w klasie config/ProjectConfiguration.class.php.

public function configureDoctrine(Doctrine_Manager $manager)
{
    $manager->setAttribute(Doctrine_Core::ATTR_QUERY_CACHE, new Doctrine_Cache_Apc());
}

Powyższy kod spowoduje, że skompilowane zapytania będą zapamiętywane w pamięci APC. Oprócz APC Doctrine może współpracować z serwerem memcached lub inną bazą danych (np. SQLite).

Cache można włączyć nie tylko na poziomie managera, równie dobrze można zrobić to w samym zapytaniu:

$q = Doctrine_Query::create()
    ->useQueryCache(new Doctrine_Cache_Apc());

Jak wspomniałem wcześniej, pamięć podręczna zapytań powinna być włączona zawsze. Na poziomie konkretnego zapytania więcej sensu ma włączanie zapamiętywania wyników:

$q = Doctrine_Query::create()
    ->useResultCache(new Doctrine_Cache_Apc());

Sympatyczny wynalazek, jakim jest YAML, jest używany w Symfony niemal na każdym kroku. I bardzo lepiej, bo to bardzo przyjazny człowiekowi format zapisu. Dokumentacja Symfony na temat YAML-a jest jednak dość lakoniczna i nie opisuje wszystkich jego możliwości. Jednym z pominiętych zagadnień są na ten przykład etykiety, które pozwalają zredukować ilość wklepywanych danych.

Etykiety najbardziej przydają się przy definiowaniu danych statycznych aplikacji (fixtures). Załóżmy, że tworzymy katalog usług hostingowych. Usługę VPS można opisać chociażby tak:

  vps_hitme_openvz_128: &vps_hitme_openvz
    Company:            hitme
    name:               OpenVZ 128
    Virtualization:     openvz
    guaranteed_memory:  128
    burstable_memory:   256
    swap_memory:        0
    disk_space:         20
    uplink:             100
    downlink:           100
    bandwidth:          50
    ip_4_addresses:     1
    ip_6_mask:          64
    root_access:        true
    is_managed:         false
    url:                http://www.hitme.net.pl/openvz-details.php
    is_verified:        true
    is_active:          true

Kolejne pakiety różniące się od powyższego tylko nazwą, ilością dostępnej pamięci, powierzchnią dyskową i transferem można opisać o wiele krócej:

  vps_hitme_openvz_256:
    <<:                 *vps_hitme_openvz
    name:               OpenVZ 256
    guaranteed_memory:  256
    burstable_memory:   512
    disk_space:         20
    bandwidth:          100

Składnia i działanie etykiet w powyższym przykładzie są oczywiste, opiszę je jedynie dla porządku. Etykietę poprzedzamy znakiem &. Dane oznaczone etykietą włączamy używając operatora << jako klucza, którego wartością jest nazwa etykiety poprzedzona *. Spowoduje połączenie tablicy oznaczonej etykietą z bieżącą tablicą. Jeśli w obu tablicach występuje ten sam klucz to zostanie użyta wartość z bieżącej tablicy. Prawda, że przydatne?