Jak jsem optimalizoval Drupal pro běh na virtuálním serveru s 4 GB RAM

S virtuálními servery mám řadu zkušeností, dobrých i těch, které mi kdysi řekly, tudy ne. Ale nejsem v tomto směru člověk, který by znovu nevstoupil do stejné řeky. Jen to dělám vždy poučen s předchozích zkušeností o trošku lépe. Doufám.

Jak to mám s virtuálními servery

S virtuálními servery jsem začal před hezkou řádkou let, 10 roků možná nebude daleko od pravdy. Weby tehdy byly méně náročné a odpovídal tomu i výkon virtuálních serverů. 256 MB RAM bylo akorát, 512 MB byl nadstandard a 1 GB bylo z říše vytoužených přání. Měl jsem tenkrát jeden virtuál u Web4U kvůli velikosti diskového prostoru a později přidal ještě jeden, abych ušetřil za hosting. Nic jako multihostingy se tehdy v Česku nenabízelo.

Bylo to řešení docela spolehlivé. Administrace přes nenastylované HTML formuláře od Web4U byla sice otřesná, ale při troše sebezapření použitelná. Ovšem problém byl v mé osobě. Nebyl jsem dostatečně zběhlý ve správě linuxového serveru přes příkazovou řádku a v instalaci bezpečnostních aktualizací. Pak to začalo. Průnik přes FTP odněkud z Bulharska, poškození jednoho webu s obrázky, následované přívalem spamu, který mailserver předinstalovaný na serveru nestíhal zpracovávat a následně kvůli tomu neběžel ani web.

Kvůli své neschopnosti toto řešit a podivné informaci od Web4U, že za přetížení mailserverů od spamu mohou hostované weby, jsem na virtuální servery na nějakou dobu zanevřel. Odešel jsem k tehdy skvělému a rychlému HostGatorovi nabízejícímu multihosting s cPanelem, tedy perfektní administraci přes webové prostředí.

Bez problémů mi tam běželo asi dvacet webů, včetně mailových schránek, vše bylo automaticky zálohované a s případnými problémy i co se Drupalu týče si ochotná technická podpora věděla rady. Dnes je to již trochu jinak, HostGator patří do jednoho velkého molochu s řadou dalších hostingů a již není tak rychlý. Přesto u něj nechávám několik anglických webů.

Později se objevil český Wedos, kam jsem přesunul svoje stěžejní weby a v průběhu let jsem začal zjišťovat, že mi poněkud nevyhovuje jeho systém aliasů, protože zkrátka nejde o klasický oddělený multihosting. Některé webové aplikace s tím mají problém, ať se snažíte nastavit pravidla v .htaccess jakkoli.

Mezitím jsem nějak přišel na Linode. Skvělého poskytovatele virtuálních serverů s vlastními datacentry v USA, Tokiu a Londýně. Začal jsem u nich s tehdy nejlevnějším tarifem a virtuálem s osmi procesorovými jádry a 512 MB RAM. Server mi jako vývojový běží dodnes, za stejnou cenu jako kdysi, ale již s 2 GB RAM. Nepamatuji si na jediný výpadek, který by zavinilo Linode. Buď jsem za to mohl sám, nebo to bylo cílené kvůli navýšení kapacity diskového úložiště.

Jediný problém, se kterým jsem se u tohoto serveru potkal, byl průnik hackera skrze chybu v debianím balíčku pro PHP. Nainstaloval si tam nástroj pro těžbu Bitcoinů, server tak byl neustále přetížený, což se Linode nelíbilo, zablokovalo přístup s výjimkou připojení na roota z mé IP adresy a čekalo na vyřešení problému. S pomocí kolegy se to podařilo, adminům v Linode jsme popsali problém, server se odblokoval a od té doby vše zase běží jako na drátkách.

S myšlenkou na produční server jsem si začal hrát před pár měsíci. Důvodů bylo několik - mám řadu hostingů a multihostingů jen kvůli rozdílným IP adresám, což se dá na serveru řešit levněji. Občas by se mi hodila nějaká nestandardní konfigurace nebo knihovna pro PHP, kterou nemá ani Wedos ve svém skvělém noLimit Extra.

Rád bych pro správu webů s Drupalem používal Drush. A konečně, chtěl bych k zálohování používat něco sofistikovanějšího, než jen spolehnutí se na zálohy od hostingu a FTP. Třeba rsync. Stejně tak bych rád přistupoval k databázím pod jedním správcovským účtem, jako to nabízí HostGator.

Když nedávno Wedos kompletně odpadl včetně své technické podpory a nedokázal zvládnout ani komunikaci, řekl jsem si, že je čas hledat alternativu. Neříkám, že je Wedos špatný, vůbec ne. Jen mi prostě přestává stačit. O zkušenostech s jeho virtuály jsem kdysi psal, nic špatného proti nim říci nemohu, ale přesto jsem začal uvažovat o dvou alternativách: Linode a dedikovaném serveru s SSD u německého Hetznera. Jeho nabídka je bezkonkurenční, alespoň co se týče srovnání s konkurencí v Česku.

Drobná zkušenost s A2 hostingem

Když jsem hledal nějakou alternativu za Wedos, padl mi do oka SSD hosting od A2 Hostingu. Nabízí multihosting s opravdu velkým výkonem, který si můžete nechat vyhradit jen pro své weby. To znělo velmi dobře! K tomu ovládání pomocí cPanelu, jako to má HostGator. A připojení přes SSH. A pozor - na SSH funkční Drush, bez nutnosti cokoli instalovat! To znělo ještě lépe.

Všechno bylo fajn. Vybral jsem nejdražší tarif tohoto hostingu na pobočce v Islandu a přesunul tam web. Běžel stejně rychle, jako u místního Wedosu s tarifem noLimit Extra. A k tomu fungoval drush. A pohodlné zálohování. Vše se tvářilo skvěle. Ovšem jen do doby, než jsem na webu vydal nový článek. Tedy dva dny.

A2 hosting má totiž na rozdíl od HostGatora proklatě nízký počet souběžných spojení do databáze,což se projeví odpadnutím webu na půl hodiny pokaždé, když tento limit převýšíte. Technická podpora se omezí na strohé "optimalizujte si web" a na výtku, že na levnějším HostGatoru tentýž web šlape při vyšší návštěvnosti v pohodě, nereagují (Wedosem jsem neargumentoval, zřejmě jej neznají, nicméně web mi tam z hostingů běžel nejrychleji, a to bez jakékoli doplňkové optimalizace).

S A2 jsem se tedy rozloučil. Myslím však, že Drupal i WordPress tam mohou při použití vhodné souborové cache eliminující databázi fungovat velmi dobře.

Zpátky u Linode

Skončil jsem ale opět u Linode, kde jsem si objednal další virtuální server. 4 GB RAM na virtuálu oproti 32 GB na dedikovaném serveru u Hetznera jsou sice rozdíl, po přepočtu na stejný výkon by virtuál vyšel výrazně špatně i finančně, ale ve stávající konfiguraci mi stačí a tedy ušetřím. Ve prospěch Linode mluví i jejich pěkný monitoring serverů LongView, nedávný kompletní přechod celé platformy na SSD a pohodlné automatické zálohování s možností jednoho vlastního slotu pro kompletní zálohu virtuálu na stisk jednoho tlačítka v administraci. To mi třeba u virtuálů Wedosu chybí.

Drupal 7 na 4GB virtuálu? Proč ne

Často se setkávám s poněkud mylným tvrzením, že Drupal je těžkopádný, přerostlý a nehodí se pro jednoduché weby. To samozřejmě není pravda, podobně jako není pravda, že WordPress se zase nehodí pro větší weby. Všechno má své klady i zápory. Samozřejmě se nedivím, když někdo takovou zkušenost získá poté, co bude neúspěšně 45 minut kopírovat a instalovat Drupal Commerce KickStart na jakýsi hosting od Savany, který padá i při provozu jednoduchého GetSimple bez databáze.

Chci tím říci, že Drupal bez problémů poběží i na nepříliš výkonném serveru a přitom může být dostatečně rychlý. Vše je to pouze o optimalizaci, a to jak Drupalu samotného, tak příslušných nastavení databáze a webového serveru. A dalších věcí na serveru samotném. Nemůžete čekat, že vše poběží na virtuálu při výchozím nastavení stejně rychle, jako na dobře dimenzovaném dedikovaném serveru.

Instalace virtuálního serveru a nezbytných aplikací

Po přihlášení do administrace Linode stačí vybrat velikost serveru, jakou požadujete, přihodit si například i zálohování (doporučuji) a zaplatit kartou. Server je zřízen během chvilky. Zbytek je na vás. Instalace operačního systému zde neprobíhá klasicky připojením ISO obrazu linuxové distribuce, ale zprovozněním disku nakopírováním nějaké už připravené kopie vybrané linuxové distribuce. Já si vybral nejnovější Debian, na který jsem zvyklý a líbí se mi z nějakého důvodu více, než třeba CentOS.

Ihned po inicializaci disku se můžete přihlásit přes SSH a provést patřičnou konfiguraci serveru. Takže aktualizaci stávajících aplikací a doplnění všeho potřebného pro provoz webu. V mém případě tedy webserveru Apache, podpory PHP a podpory MySQL. Neinstaloval jsem mailový server, abych předešel případnému přetěžování serveru spamem. Poštu mám stejně u Google a Microsoftu. Vůbec jsem neinstaloval podporu FTP, postačí mi SSH.

Doplnil jsem PhpMyAdmin a Webmin, který nakonec stejně nevyužívám a brzy půjde pryč. Pokoušel jsem se o instalaci ISPConfigu, který mám na vývojovém VPS a pomáhá mi s tvorbou subdomén a databází. Nakonec jsem jej ale zavrhl. Na produkčním serveru nebudu s doménami a databázemi šachovat tak často, abych to nezvládl přes příkazový řádek a úpravou konfigurace pro Apache.

Naopak jsem si přidal Midnight Commander, přeci jen alespoň nějaký grafický pohled a udělátko pro práci se soubory ocením i v Linuxu. Věci typu fail2ban a další rozepisovat nebudu.

Apache + Perconna + PHP-FPM

Linode má rozsáhlou dokumentaci a spoustu návodů, které vám mohou být nápomocny při instalaci i nastavování serveru. Rád jsem některých z nich využil. Rozběhal jsem Apache, upravil výchozí konfiguraci podle doporučení pro svou velikost paměti a pustil se do databáze.

Místo klasické MySQL jsem nainstaloval její fork v podobě serveru Perconna. Funguje úplně stejně, ovládá se stejnými příkazy, jen by měl být o něco rychlejší než normální MySQL, což se mi subjektivně potvrzuje. Žádným benchmarkem a řečí čísel jsem si to ale neověřil, prostě jsem jen dal za pravdu jiným.

O PHP-FPM jsem slyšel jako o rychlejší alternativě ke klasické instalaci PHP v podobě FastCGI. Takže jsem si instalaci na svém virtuálu zkonfiguroval právě pro PHP-FPM, které by mělo být opět rychlejší. Zase jsem přitom využil knihovnu s dokumentací a návody u Linode.

APC pro rychlejší PHP

Do výše popsaného nastavení jsem na server nakopíroval web s Drupalem 7 a zkusil nějaké načítání a benchmarky. Vypadalo to slušně, web běžel rychle, ale subjektivně se mi stále zdál o něco pomalejší, než u Wedosu. Mimochodem, na podobné testy můžete zkusit vypnout cache v prohlížeči a použít stránku Which loads faster.

Ze zkušeností jiných jsem usoudil, že bude potřeba cacheovat samotné PHP soubory. Dnes bych řekl, že je to logické i pro laika. Každá webová aplikace skládající se z PHP souborů je neprve zpracována tím, že se její soubory načtou, přeloží se do binárního kódu, spustí se a jejich výstup je pak dán webovému serveru pro odeslání do webového prohlížeče návštěvníka webu.

Z toho je zřejmé, že u redakčních systémů jako je velká trojka Drupal, Joomla a WordPress je nějaká opcode cache docela dobrý nápad. Nasadil jsem tedy na svůj virtuál u Linode APC, zapnul si monitorování a rázem jsem výrazně zvýšil výkon celého webu. Doporučuji si pohrát s výchozím nastavením a případně přidělit APC větší paměť, než je výchozích 32 MB. V monitoringu můžete pohodlně sledovat, jak je APC využíváno a třeba, které PHP soubory jsou nejčastěji zpracovávány. U Drupalu je krásně vidět práce se šablonami.

Po pravdě nechápu, proč na některých serverech zákazníků, ke kterým mám přístup, žádné APC ani nějaká alternativa není. Přitom tam Drupal neběží nejrychleji a paměť serveru je nevyužitá, stejně jako procesorový výkon.

Memcache ani Varnish zatím nepotřebuji

Určitě by se dalo hrát i s Memcache a Varnishem, tedy uchováváním sestavených webových stránek v operační paměti. Konfigurace a především odladění je na delší dobu, takže jsem se do toho zatím nepustil. Pravdou je, že Drupal mi běží dostatečně rychle i bez těchto věcí.

Google Mod PageSpeed pro optimalizovaný přenos dat webové stránky

Jedním z vylepšení, které jsem na server nasadil, je modul pro webový server Apache s názvem Mod PageSpeed. Psal jsem o něm nedávno v samostatném článku, viz odkaz. Tento modul sice trochu zvedne zátěž procesoru, zráoveň se ale postará o optimalizaci CSS a JavaScriptu posílaného z webu do prohlížeče. Upraví hlavičku stránky tak, že více souborů spojí do jednoho.

V Drupalu to oceníte, protože ne všechny doplňkové moduly a zejména témata vzhledu napojují CSS a JS do webu správným způsobem, takže i při jejich zapnuté agregaci v nastavení Drupalu není vše spojeno do jednoho souboru a zmenšeno. Co však Drupal nezvládne, Mod PageSpeed dodělá. Rovněž se tento doplněk stará o lepší kompresi obrázků a odstranění nepotřebných dat z obrazových souborů.

Výsledkem tedy není zrychlení webu ve smyslu jeho generování na serveru, ale menší počet dat, která tečou ze serveru do prohlížeče a tudíž rychlejší načítání v tomto směru. Vřele doporučuji.

Nezbytné úpravy přímo v Drupalu

Po celou dobu, co mi web běžel na Wedosu s tarifem noLimit Extra, jsem v Drupalu používal jenom výchozí cacheování. Stačilo to a web byl hodně rychlý. Současné VPS je přeci jenom virtuál, takže jsem se rozhodl cacheování trochu pomoci.

Konkrétně jsem nasadil modul Authcache, který v Drupalu umožní cacheovat stránky i přihlášeným uživatelům, což standardní cache neumí. O důvod víc, proč Authcache zapnout. Instalace a zprovoznění současné verze je otázkou chvilky. Nevyžaduje už žádné složité úpravy konfiguračních souborů, jen doplníte jeden nebo dva řádky z readme.txt do souboru settings.php.

I když cacheování vylepší, tak standardně Authcache stále sahá do databáze, do cacheovacích tabulek. Rozumí si však například s modulem pro podporu Memcache (nastavení jsem zatím odložil, viz výše) a s modulem File Cache. A na ten jsem vsadil. Na rozdíl od jiného známého cacheování do souborů v podobě modulu Boost totiž File Cache není řízen přes .htaccess, ale přes logiku Drupalu. A drobná režie části jádra Drupalu v PHP není až tak velký problém. Vrátí se vám to v podobě jednodušší instalace modulu i smysluplnějšího mazání a obnovy cache. Při použití Boostu je to totiž tak trochu mimo vaši kontrolu.

Přidal jsem ještě modul Cache Expiration, pro lepší řízení expirace cache. Doporučuji jej i vám, pokud používáte jen výchozí cacheování Drupalu. S pomocí tohoto modulu nastavíte, aby se například vymazala cache pro titulku po vydání nového článku, došlo k obnově cache pro aktualizovaný článek nebo po přidání komentáře k němu a podobně. Web pak bude stále cacheovaný a přitom na něm nebude viset starý obsah. A vy si budete moci dovolit prodloužit interval pro zachování dat v cache.

Nač se chystám do budoucna?

Na optimalizaci webu s Drupalem na virtuálním serveru bude ještě dále pracovat. Zaujalo mě, jak jsou dnes virtuální servery už schopné fungovat i s o něco větším webem a přitom dostatečně rychle. Stačí jen trošku upravit výchozí nastavení.

Rád bych časem vyzkoušel podporu SPDY a umožnil tak další zrychlení při načítání webu do prohlížeče. Dnes to podporují prakticky všechny hlavní programy pro prohlížení internetu. Prozatím to na mé straně vázne u implementace SSL certifikátu, který je pro toto vylepšení potřeba.

Chystám se pohrát si s memcache a uvidím, jaké případné problémy a výzvy přinese přesun dalších webů na stejný server. Jsem zvědav na změnu zátěže a chování APC. Dále bych rád nastavil Postfix tak, aby maily z webu odesílal přes službu Mandrill (doporučuji kouknout na odkazovaný článek).

Přímo v Drupalu si ještě budu hrát s nastavením cache u jednotlivých View. Interval pro jejich cache může být nezávislý na tom systémovém a v praxi některé výpisy tvořené modulem Views klidně mohou být v cache celý den bez obnovy, aniž by to webu ublížilo.

Update: inspirací při mých pokusech mi byl starší článek Fast Drupal on Linode.