Dotaz: Používání cache na HTTP serverech

[Kit]

V diskuzi o starších serverech jsme se dostali k tématu http://www.abclinuxu.cz/poradna/hardware/show/427914#34. V minulosti jsem tento postup s oblibou používal tam, kde hosting nenabízel PHP. Stránky jsem si vygeneroval lokálně v PHP a na server putovaly soubory v HTML, JS, CSS apod.

Dnes už téměř každý webserver nabízí nějaké dynamické generování stránek a statické předgenerování HTML či jiného obsahu upadl do polozapomnění. Nebo snad ne?

Objevily se nejrůznější cache, z nichž nejméně mi dávají smysl cache v aplikaci - Memcache, Redis v roli cache apod. Dále máme cache databázové, souborové, proxy a další, které umí svůj obsah udržovat v čistotě a z našeho pohledu jsou transparentní. Jen je správně nakonfigurovat.

Jaké používáte cache na webových serverech a jak je konfigurujete, abyste dosáhli maximálního výkonu aplikace?

Odpovědi

[Josef Kufner]

Dnes už téměř každý webserver nabízí nějaké dynamické generování stránek a statické předgenerování HTML či jiného obsahu upadl do polozapomnění. Nebo snad ne?

Naopak. Statické weby prodělaly před pár lety renesanci díky Github Pages (a později se přidal i Gitlab). Vyrojilo se spousty generátorů a právě v kombinaci s Gitem a continuous integration/deploy to je velmi užitečná a pohodlná věc. Ve výsledku upravíš lokalní soubor např. v Markdownu, commitneš změny, CI na serveru se pushem vzbudí, vyrobí nový web a nahraje změny na statický hosting.

Pro jednoduché prezentace projektů a dokumentace programů je to ideální. Sám takto mám dva weby, jeden jsem konvertoval právě z letitého PHP na Jekyll. Pokud už máš web rozběhnutý a chceš udělat nějaké menší změny či něco připsat, vystačíš si s mobilem (MGit) a línou wifi z baru na pláži (vyzkoušeno).

[Kit]

Díky za inspirující seznam generátorů. Některý z nich se mi určitě bude hodit alespoň jako polotovar.

[Petr]

A co kvalita? Treba typos? Zadny review proces? Davat veci rovnou do produkce z gitu je mozna rychle, ale bez zaruky kvality.

[Josef Kufner]

Naopak. Automatizace procesu přináší daleko vyšší záruky kvality.

Na to, aby mohlo proběhnout review a nešlo to do produkce rovnou, máme merge requesty a větve. Tedy udělá se feature branch, jakmile je odladěno, vytvoří se merge request, proběhne review, mergne se do masteru, z masteru se udělá staging, ten se otestuje a pokud projde, posune se produkce. Všechny či jen vybrané větve pak mohou mít automaticky generované a deployované testovací prostředí, kde si to můžeš prohlédnout bez vlivu na produkci.

A nebo to je prostě nějaký malý web, kde nevadí, když bude chvilku nějaká chyba a necháš posílat master rovnou do světa. I tak je ale výhoda v tom, že v deploy procesu neuděláš chybu a na nic nezapomeneš. Navíc není problém tam mít nějaké testy, které deploy zastaví (selže generátor), či aspoň varují (mám takto automatické kontroly odkazů, ale až po deploy).

[Josef Kufner]

Objevily se nejrůznější cache, z nichž nejméně mi dávají smysl cache v aplikaci - Memcache, Redis v roli cache apod. Dále máme cache databázové, souborové, proxy a další, které umí svůj obsah udržovat v čistotě a z našeho pohledu jsou transparentní. Jen je správně nakonfigurovat. Jaké používáte cache na webových serverech a jak je konfigurujete, abyste dosáhli maximálního výkonu aplikace?

Memcache je ptákovina. Tím, že tam je socket a stejně se komunikuje po síti, je to zhruba stejně rychlé jako MySQL s jednoduchým dotazem. Pokud je databáze dobře udělaná, memcache akorát zdržuje. Daleko lepší je nastavit větší cache databázovému serveru, neboť to pomůže víc a aplikace se zjednoduší.

Redis jsem poslední dobou viděl hodně používat na ukládání sessions. Zdá se, že to funguje. Přijde mi však, že ve většině případů to je zbytečná komplikace navíc. Pokud ale je aplikace nasazená v cloudu, tak už to má opodstatnění (lokální soubory, kam se to defaultně ukládá, nejsou sdílené mezi servery). Otázkou je, zda malá SQL tabulka neudělá stejnou práci.

Souborové cache jsou zajímavé, pokud se to kombinuje s nějakým dalším mechanismem. Pokud HTTP server umí X-SendFile, tak stačí nakešovat do souboru a předat jméno souboru serveru, ať už to pošle sám. PHP frameworky zas často generují PHP soubory (např. Twig a snad všechny DI kontejnery), které pak PHP nakešuje do OPcode cache, takže to vlastně zůstává předkompilované v paměti.

Další hezká věc byla APCu, což bylo docela jednoduché key-value úložiště ve sdílené paměti. Sice taková cache je sdílená jen v rámci jednoho serveru, ale za to je neskutečně rychlá. Škoda, že už se to nevyvíjí (skončilo to s PHP5).

[Kit]

• Memcache - souhlas
• Sessions v Redisu zní zajímavě, ale Redis toho umí víc a je mi docela líto ho používat na takovou prkotinu. Ostatně PHP má podporu pro sessions v MySQL a když se použije engine MEMORY...
• Měl jsem na mysli souborové cache, které jsou součástí systému a jsou zcela transparentní. Když stejný konfigurační soubor čteš třeba tisíckrát za sekundu, tak to na disk hrábne jen napoprvé
• APCu by mělo jít pro PHP7 přidat přes PECL. Nezkoušel jsem

[Josef Kufner]

APCu by mělo jít pro PHP7 přidat přes PECL. Nezkoušel jsem

No právě. Už to není hezky v základu, takže to bude na serverech skoro vždy chybět.

[Sten]

Memcache je ptákovina? To je zase rada. Memcache se samozřejmě nepoužívá jako náhrada SQL cache, ale třeba pro ukládání vygenerovaných částí stránek nebo celých stránek, kdy je nelze cachovat na webserveru (třeba kvůli tomu, že jsou závislé na session). Nebo data získaná z pomalých zdrojů, jako třeba předparsované logy nebo data pushnutá z dalších serverů či generovaná asynchronní operací.

Ukládání session do SQL? Možná u malého webu to funguje, ale cokoliv víc zatíženého bude mít velký problém, když najedou každý request bude generovat zapisující transakce (potřebujete přinejmenším prodloužit platnost session), což kromě serializace všech requestů nad jednou tabulkou také zlikviduje SQL cache a vydrtí disky.

[Josef Kufner]

Memcache jsem párkrát potkal právě v místě, kdy se někdo snažil urychlit SQL dotazy (samozřejmě to víc zdržovalo než zrychlovalo). Takže vyhození Memcache a opravení databáze výrazně pomohlo.

Kešování kusů vykreslených stránek sice zní lákavě, ale neskutečně to komplikuje aplikaci. Navíc ten dotaz na memcache chvíli trvá a šablonovací systémy nejsou zas tak pomalé. Smysl to může mít u pomalých zdrojů dat, nebo když je potřeba něco složitě počítat, ale v takových případech zas ta data obvykle mívají nějakou strukturu, kterou je dobré zachovat a nějak ji využít (nad logem se hodí mít index, data pushnutá z dalšího serveru bude vhodné aktualizovat po částech, …). To pak je Memcache už moc slabý nástroj. A pokud je potřeba obsloužit opravdu hodně uživatelů, raději bych sáhnul po APCu, kdy odpadne komunikace po socketu (jinak to je prakticky totéž).

Co se session v SQL týče, Innodb si zamyká při updatu jednotlivé řádky, takže by to paralelizaci nemělo rozbít (ale je to dobrá připomínka). Co se SQL cache a disků týče, pro méně navštěvované weby to není problém. Pokud se tabulka se sessions vleze celá do cache, tak tam prostě bude a stačí nechat cache dostatečně velkou. Zápisy lze snadno omezit tím, že se session bude prodlužovat jen občas – například pokud už vypršela alespoň čtvrtina životnosti session, takže pokud uživatel jen čte a udělá 1 rq/min v session, která je na hodinu, zapíše se na disk jednou za 15 minut a ani si toho nevšimne. Pro delší session to je zcela bezproblémové.

[trekker.dk]

A pokud je potřeba obsloužit opravdu hodně uživatelů, raději bych sáhnul po APCu, kdy odpadne komunikace po socketu (jinak to je prakticky totéž).

Až na to, že to bude fungovat jenom u mod_php nebo za použití posix shared memory - přičemž obojímu je lépe se vyhnout.

Innodb si zamyká při updatu jednotlivé řádky, takže by to paralelizaci nemělo rozbít

InnoDB na sessions? No potěš koště.

Zápisy lze snadno omezit tím, že se session bude prodlužovat jen občas

Pokud ovšem do té session nezapisujete data, což aplikace dost často dělají.

[Kit]

Memcache je líná potvora, která jenom zdržuje. I ten Redis je rychlejší a přitom je o dva řády lepší ve schopnostech.

Když už bych do Memcache něco ukládal, tak ne v HTML, ale v XML, aby se to dalo snadno umístit do výstupní šablony. A než se piplat s XML, je lepší to tahat rovnou z SQL.

Serializaci session nedělá SQL, ale PHP, tedy databázi to nijak nezatěžuje. Transakce se nepoužívají, neboť nejsou potřebné. Cache se nezlikviduje, session je typicky velmi krátký string. Souborové systémy s tím také nemají problémy, proč by měla mít databáze?

Možná nejlepším řešením pro sessions bude starý dobrý ramdisk.

[MP]

Nojo. Ale k cemu ramdisk, kdyz obvykle tu session potrebujete sdilet mezi servery. To je hlavni pouziti memcache(d). Redis je druha varianta na toto pouziti, ale ponekud slozitejsi na konfiguraci a HA. A davat session do databaze je sice mozne, ale zbytecne zatezujici, pokud to zase neni primo v nejake cache.

[Kit]

Když databáze používá engine MEMORY, tak se cache nedělá - byla by zbytečná.

[MP]

To neznam, ale muze to tak byt. Jenze v pripade databaze stale musite resit funkcionalitu z hlediska HA.

[Kit]

Neřeší to náhodou databáze sama?

[cronin]

Mám už nejaký ten rok skúsenosť s vývojom a nasadzovaním enterprise aplikácií a prakticky vždy platilo, že kdekoľvek sa píše "cache", číta sa "problém". Niektorí architekti navrhujú Varnish medzi dvomi Nginxami, Nginx medzi dvomi Varnishmi, replikovaný klaster Memcache serverov pristupovaný cez Mcrouter a podobné obskurnosti bez toho, aby sa niekto reálne unúval zmerať, aký je rozdiel vo výkonnosti bez cache a s ňou.

Mantra je "measure, don't guess", a ak sa do infrašturktúry pridá komponent, ktorý vlastne ani sám o sebe neposkytuje business funkcionalitu, musí tento komponent merateľne riešiť signifikantne viac problémov, ako prináša.