Devel.cz Lupa Měšec Podnikatel Root Zdroják.cz DigiZone Slunečnice Vitalia TopDrive KupDnes Navrcholu NovýTarif Dobrý web Weblogy Woko Jagg Computer.cz SK: MojeLinky

Hlavní navigace

Django: Kešování a škálování

Velká návštěvnost webového projektu sice autora většinou těší, ale často přináší i problémy se stabilitou a dostupností systému. V předposledním díle seriálu o frameworku Django se proto podíváme na kešovací systém Djanga a na to, jak pomocí něj zvládnout příval návštěvníků.

Tweetni to Twitter Jaggni to! Jagg Del.icio.us Delicious

Kešování obsahu

Při každém požadavku prohlížeče se stránka musí před odesláním sestavit. To zahrnuje načtení dat z databáze přes pohled a následné vygenerování HTML kódu dle šablony. Tento proces většinou není příliš rychlý, proto se od určité návštěvnosti vyplatí sestavené stránky ukládat do vyrovnávací paměti a poté je při příštím požadavku servírovat odtamtud. Tuto vyrovnávací paměť (nebo též keš) může Django ukládat do souborů, databáze, nebo použít externí kešovací systém, jako je např. memcached, který drží keš v operační paměti serveru.

Úložiště keše

Ke specifikaci úložiště slouží konstanta CACHE_BACKEND, do níž je potřeba zadat URL. Výchozí hodnota je locmem:///, což je naprosto základní kešování procesů, které není vhodné používat na produkčním serveru. Ukládání keše do souborů se zadává pomocí prefixu file://, po kterém následuje absolutní adresář. Kupříkladu kdybychom chtěli udržovat keš v adresáři /tmp/cache/, připíšeme do souboru settings.py tento řádek:

CACHE_BACKEND = 'file:///tmp/cache/'

V případě ukládání keše do databáze to je trochu složitější. Nejprve musíme vytvořit kešovací tabulku pomocí příkazu python manage.py createcachetable <tabulka>. Takže když bychom chtěli keš držet v tabulce cache, stačí napsat v adresáři projektu příkaz:

$ python manage.py createcachetable cache

… a vytvoří se nám odpovídající tabulka. Poté je potřeba zadat do konstanty CACHE_BACKEND prefix db:// následovaný názvem tabulky, tedy v našem případě:

CACHE_BACKEND = 'db://cache/'

Další možností je použít kešovací systém memcached, jenž se zadává prefixem memcached:// následovaným adresou serveru. V případě použití více serverů se oddělují adresy středníkem. Pokud máme jeden memcached na lokálním počítači a druhý na adrese 192.168.1.100, nastavení konstanty vypadá takto:

CACHE_BACKEND = 'memcached://127.0.0.1:11211;192.168.1.100:11211/'

Nastavení keše

Po výběru úložiště je potřeba zapnout kešování stránek. K tomu slouží dvě middleware komponenty: 'django.middleware.cache.UpdateCacheMiddleware' a 'django.middleware.cache.FetchFromCacheMiddleware'. Ty přidáme do konstanty MIDDLEWARE_CLASSES, což v projektu z minulých dílů vypadá takto:

MIDDLEWARE_CLASSES = (
    'django.middleware.cache.UpdateCacheMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware',
    'django.middleware.locale.LocaleMiddleware',
    'django.middleware.cache.FetchFromCacheMiddleware',
)
Pozor, na pořadí middleware komponent záleží. Modul UpdateCacheMiddleware musí být vždycky na prvním místě a FetchFromCacheMiddleware na posledním.

Tím zapneme kešování v celém projektu. V případě, že na serveru provozujeme více projektů a ty sdílejí úložiště, měli bychom nastavit v každém projektu jiný obsah konstanty CACHE_MIDDLEWARE_KEY_PREFIX, aby si projekty navzájem kešované stránky nepřepisovaly. Dále máme možnost pomocí konstanty CACHE_MIDDLEWARE_SECONDS nastavit dobu kešování (udává se v sekundách). Tuto volbu máme možnost změnit také přes argumenty konstanty  CACHE_BACKEND.

Pokud byste potřebovali nastavit dobu kešování u jednotlivých pohledů, dá se to lehce zařídit pomocí dekorátoru cache_page. Je možné kešovat i samotné části šablon, k čemuž slouží značka {% cache %} .

Škálování

Správné nastavení keše je ale jenom začátek. Při provozování projektu s narůstající návštěvností se časem nevyhneme rozdělení zátěže na více serverů. Ukážeme si několik modelových případů. Podotýkám, že popisovaná návštěvnost je odhadovaná a může se lišit i o několik řádů.

Projekt s nejvýše tisíci návštěvníky denně

Pro projekty s malou návštěvností bohatě stačí jeden fyzický server. Už v této fázi se vyplatí zapnout kešování aspoň do souborů nebo databáze. Jestliže očekáváme postupný nárůst zatížení, není dobrý nápad použít databázový systém SQLite, protože se špatně škáluje. Doporučuji použít databázový systém PostgreSQL. (Typické nasazení se občas označuje zkratkou LAPD, což znamená Linux, Apache, PostgreSQL a Django.)

Projekt s nejvýše desetitisíci návštěvníky denně

Jakmile přestane osamocený server stíhat obsluhovat požadavky návštěvníků, následujícím logickým krokem je přesunout databázovou část na další stroj. V tomto okamžiku  totiž latence lokální sítě přestane být větším znevýhodněním než přepínání mezi zpracováváním webového požadavku a hledáním dat v databázi. Jednoduše řečeno, jeden server nebude dělat dvě věci najednou a bude se zabývat pouze jednou úlohou. Databázový server doporučuji vybavit co největším množstvím operační paměti, aby se plně využilo kešování databázových dotazů.

Dále je vhodné servírovat statické soubory zvlášť z vlastního odlehčeného webserveru (např. lighttpd nebo tux). Je to z toho důvodu, že na odesílání statických souborů není potřeba plně vybavené Apache včetně Djanga. Pokud používáte k vývoji nějakou z populárních javascriptových knihoven, můžete si je nechat servírovat přes Google AJAX Libraries API. Výhodou tohoto řešení je, že pokud návštěvník předtím někdy navštívil stránku, na které také používají servírování dané knihovny Googlem, bude ji mít už načtenou v keši prohlížeče.

Projekt s více než statisíci návštěvníky denně

Pokud vašemu projektu přestal stačit na každou funkci jeden server, gratuluji, váš projekt se stal masově oblíbeným. V této fázi doporučuji zprovoznit memcached na samostatném počítači a nechat vracet výsledky dotazů z něj. Následujícím krokem je rozdělení jednotlivých služeb na více strojů a vyvažovat mezi nimi zátěž. K tomu slouží tzv. load balancer (např. Perlbal nebo HAProxy), který podle určitého klíče vybere webserver pro obsloužení požadavku a uživatele na něj přesměruje. Tak můžeme postupně rozšiřovat počet webových serverů. Podobně lze přidávat databázové servery, kupříkladu PostgreSQL podporuje několik způsobů vyrovnávání zátěže.

Po zprovoznění load balanceru je pokračování jednoduché — stačí podle potřeby dodávat další a další webové, databázové a kešovací servery…

Související odkazy

Příště zakončíme tento seriál závěrečným shrnutím a několika tipy a triky.

Pavel Dvořák

Pavel Dvořák

Autor je dlouhodobým studentem Fakulty informatiky, webový nadšenec a programátor — nejraději programuje v jazycích Haskell a Python.

Školení: Návrh a používání MySQL databáze

 

Naučte se používat jednu z nejrozšířenějších databází. Dozvíte se vše potřebné od návrhu až po samotné využití MySQL v projektech.

Školení pro všechny, kteří se chtějí naučit efektivně pracovat s MySQL nebo se v práci s touto databází zlepšit.

Přihláška a podrobné informace

Přehled názorů

Load Balancing
Martin 20. 11. 2009 09:12
Nový
└ 
Re: Load Balancing
Pavel Dvořák 20. 11. 2009 17:10
Nový
 
└ 
Re: Load Balancing
Kaplan Věroš 21. 11. 2009 13:45
Nový
Dalsie moznosti
bitsmith 20. 11. 2009 15:10
Nový
Tisíc návštěvníků za den?
Kaplan Věroš 21. 11. 2009 13:50
Nový
└ 
Re: Tisíc návštěvníků za den?
Pavel Dvořák 22. 11. 2009 16:53
Nový
 
└ 
Re: Tisíc návštěvníků za den?
Kaplan Věroš 22. 11. 2009 22:16
Nový
CACHE_MIDDLEWARE_ANO NYMOUS_ONLY
Pavel Dvořák 27. 11. 2009 14:09
Nový
└ 
Re: CACHE_MIDDLEWARE_ANO NYMOUS_ONLY
Petr Meissner 12. 1. 2010 15:18
Nový
 
└ 
Re: CACHE_MIDDLEWARE_ANO NYMOUS_ONLY
Pavel Dvořák 12. 1. 2010 15:59
Nový
       

Tento text je již více než dva měsíce starý. Chcete-li na něj reagovat v diskusi, pravděpodobně vám již nikdo neodpoví. Pro řešení aktuálních problémů doporučujeme využít naše diskusní fórum.

Zasílat nově přidané příspěvky e-mailem