V druhém díle Levný vývoj nebo levný provoz? A což takhle to neřešit? jsme nastínili strategii Drupalu na překonání výkonnostních obtíží při zachování vysoké přívětivosti pro vývojáře a z toho plynoucí efektivitu. Zbývá tu ale ještě jedna otázka: V čem konkrétně spočívají výkonnostní potíže, které překonává Drupal důrazem na cache, která je od základu vestavěná? To je dobrá otázka a dnes si ji zodpovíme. Poté bude již možné popsat konkrétní prostředky, kterými Drupal řeší tyto konkrétní problémy.
Obecné datové modely
Drupal umožňuje vytváření datových struktur a vazeb mezi nimi (Typy obsahu a Kategorie) pomocí grafického uživatelského rozhraní. Ať si přejeme uchovávat informace o vydaných publikacích nebo oblíbených restauracích, vždy máme k dispozici jednotný nástroj na:
- vytvoření datových položek a nastavení vazeb, jak co s čím souvisí,
- vkládání a úpravu jednotlivých záznamů,
- tvorbu stránek, které data prezentují našim návštěvníkům.
To vše bez nutnosti napsat jedinou řádku kódu. Pro programátory jsou navíc k dispozici nástroje jak pracovat s libovolnou datovou strukturou vždy stejným způsobem. To je skvělé, ale nese to s sebou i obtíže. Něco takového je možné pouze s použitím obecného datového modelu.
Cena za uživatelsky přívětivou správu datového modelu je opravdu vysoká. Obecný datový model v databázi nutí vývojáře k používání neefektivních způsobů, jak číst a zapisovat data do databáze. Filtrování dat se stává strojově velmi náročnou akcí - a to nemluvíme o agregacích potřebných pro reportování.
Vysoké požadavky na vysokou konfigurovatelnost všeho možného situaci ještě více komplikují. A když připočteme ještě důraz na robustnost (logování akcí pro jejich reverzibilitu) a bezpečnost (řízení přístupovývh práv), je výsledná databáze opravdu košatá a nesnese časté použití.
Drupal proto volí prostředky, jak používat databázi pouze na dlouhodobé a stabilní uchovávání dat v konzistentní podobě. Pro běžný provoz se opírá o různé druhy cache - ale o tom až přístě.
Modularita
Pokud chceme izolovat jednotlivé funkcionality do samostatných bloků, zvolíme modulární architekturu. To samo o sobě nepřináší závažnější zpomalení. Ambice Drupalu ve smyslu možné síly modulů, jejich univerzálnosti a vzájemné spolupráci ale míří mnohem dál.
Sestavování stránky je v Drupalu velmi komplexní proces skládající se z mnoha jednotlivých akcí - autorizace, datové operace, sestavování kódu výsledné stránky, atd. V každém kroku se Drupal zeptá všech modulů, zda nechtějí přispět svojí troškou do mlýna. Jednotlivé fáze zpracování požadavku jsou implementovány jako události a k jejich obsluze jsou přizvány všechny moduly.
Každý modul tak může vstoupit do jakékoliv fáze řešení jednotlivého požadavku. každý modul může definovat i události vlastní. Příslušný mechanismus se jmenuje „hook” - háček. Pomocí něj se modul „zahákne” do fronty akcí příslušející dané konkrétní akci. Je to velmi dobrý a obecný prostředek, který umožňuje modulům jednotné a silné ovlivnění fungování celého systému. Drupal je proto opravdu flexibilní.
Oněch událostí je celá řada a modulů bývá velké množství. Jen někdy se ale stává, že konkrétní modul chce opravdu ovlivnit konkrétní fázi zpracování požadavku. Celý proces je pomalý a navíc neefektivní, protože většina odpovědí modulů je "Děkuji, nechci ovlivnit tuto fázi".
Moduly musí samozřejmě také být schopny spolupráce, čili každý modul musí umět kdykoliv použít jakoukoliv funkcionalitu jakéhokoliv modulu. Aby nebyl tento proces zbytečně kostrbatý, opírá se Drupal o metaprogramování, čili dynamické volání funkcí podle hodnot uložených v řetězci nebo pomocí „magických” funkcí a metod (uživatel je explicitně nedefinuje, ale přesto „existují”). Metaprogramování je samozřejmě také provozně dražší než obyčejné programování.
Moduly mohou také reimplementovat některé vestavěné funkce Drupalu a i to musí být náležitě prověřeno a případně dynamicky použito. Ani tady nemusí být režie zanedbatelná.
Modularita v Drupalu tak nabízí přehledný, jednotný a obecný postup implementace vlastní funkcionality. Jako v případě obecných datových modelů se tak děje jen za cenu výraznějšího nárůstu práce pro samotný Drupal.