Rychlý Drupal? Zkušenosti?
Rád bych se zeptal na jakékoliv zkušenosti, jak dosáhnout rychlého Drupalu (6/7). Prvotním cílem je, aby zvládal alespoň u statických stránek pro anonymní uživatele špičky s deseti až několika desítkami uživatelů za sec. (což zhruba odpovídá zveřejnění odkazu na náš web KohoVolit.eu na idnes.cz, sme.sk apod.). Zhruba bychom potřebovali zrychlit alespoň tak 5× (dle testů níže). Toto potřebujeme pouze několikrát do roka. Co se vám osvědčilo?
Provedl jsem testování u sebe na laptopu (Ubuntu, 2G paměť) s čistě nainstalovaným D6.20 a D7.0 a výsledky mi vycházejí dost tristní (pro Drupal), testováno pomocí příkazu ‚ab‘. Když shrnu moje testy:
Pokud mám stejnou stránku (node/1 jen s jménem a nápisem ‚Test‘) různě načítanou, tak to zhruba odpovídá (počet stránek/sec):
- 100% čisté html
- 70% generováno z php (jen příkaz echo)
- 50% generováno z mysql, dotaz spuštěn v php
- 35% generováno z php (jen příkaz echo) + prázdný for cyklus do 10000
- 15% generováno z mysql, dotaz spuštěn v php 100×
- 8% Drupal 6.20, všechny cache zapnuté (Caching mode: Normal, kvůli i18n)
- 4% Drupal 7.0, všechny cache zapnuté (pozn.: 2× větší soubor)
- 1% Drupal 6.20 bez cache
- <1% Drupal 6.20 cache + Boost (?!)
- .5% Drupal 7.0 bez cache (pozn.; 2× větší soubor)
Dále Lighttpd je o něco rychlejší než Apache2, ale projeví se to až u nějakých 500 stránek/sec (netýká se tedy moc Drupalu)
Drupal 6.20 a 7.0 mi vycházely zhruba stejně rychlé při zohlednění 2× větší stránky u verze 7.0, u větších stránek tedy zatím odhaduji srovnatelnou rychlost.
Detailní přehled testů: http://www.editgrid.com/…eedup-drupal (můžete doplnit i vlastní testy s různým nastavením)
Hlavní RSS kanál
Skus si pohladat nieco
Skus si pohladat nieco o Pressflow + Varnish. Dalej by bolo zaujimave vediet ci pouzivas na serveri APC (pripadne inu bytecode cache). Spustu zaujimavych clankov o optimalizacii behu Drupalu najdes zasa tu http://2bits.com/…b-sites.html.
zkušenosti?
Díky za tip (pressflow + něco zrovna zkoušim). Nicméně moje otázka byla spíš, zda někdo má konkrétní zkušenosti, jak reálně dosáhl rychlého Drupalu.
Např. „na virtuálním serveru s 1G paměti jsme nainstalovali pressflow + varnish + něco dalšího + ještě něco dalšího a zvládá to 10 anonymních uživatelů/sec“
Tolik drupalistů, určitě už to někdo dělal. Rychlost je skutečně ta klíčová (a vlastně jediná) věc, co nás zatím odrazuje od dalšího použití drupalu a to na drupalu jedeme už dva roky (několik měsíců člověk vyvíjí aplikace a v klíčovém okamžiku server spadne kvůli pomalému drupalu…)
Díky za zkušenosti
Asi sa na to treba pozriet
Asi sa na to treba pozriet z pohladu kde su slabe miesta – cize zapnut Devel + vypis SQL + trvanie vykonavania stranky. Ak mas na titulke 300 – 400 SQL tak je to bolave. Ja som raz upravoval jednu stranku na beznom hostingu kde bola titulna strana strasne pomala. Nakoniec som si upravil cache-ovanie nodov zobrazovanych na titulnej strane tak aby sa HTML ulozilo do cache a menili sa len hodnoty ktore sa mohli zmenit. Dost rapidne to urychlilo stranku – ked som to skusal na vlastnom serveri tak o zvladlo aj 60 dotazov za sekundu. Na hostingu to ale stale bolo mizerne :) aj ked viditelne sviznejsie.
i prazdny drupal je pomaly (zvlada malo requestu za sec.)
Zkusím pohledat, ale problém mám v tom, ze čistá instalace s cachovanim zapnutym (příp. s Boostem) a jedním jediným nodem mi ten node/1 zvládá asi tak 5 za sec., coz je prostě málo, 60 by už by bylo dobrý (ta samá stránka uložená jako html nebo přes php jen pomocí echo je někde kolem 500–1000× za sec). To je ten problém, že vůbec nejsem schopen dosáhnout rychlého drupalu ani při zcela nové instalaci, prázdného – při zobrazení toho node/1 tam kolem nic není (je tam jenom blok s přihlášením, nápis test a to je vše)
A co teda to APC? Mně třeba
A co teda to APC? Mně třeba celkem pomohla xCache…
zajímavý článek popisující
zajímavý článek popisující testování a ladění výkonu drupal webu pomocí ab.
http://www.appnovation.com/…-your-server
A čo DB pri
A čo DB pri testoch?
Nechci zakládat nový téma,
Nechci zakládat nový téma, tohle mi příde dostatečný. Myslíte, že je lepší vytvořit si menu o pár položkách ručně než používat taxonomy menu, menu block atd.? Sice člověk příde o tu automatizaci, na druhou stranu každá úleva dobrá
Taxonomy menu je brutálně
Taxonomy menu je brutálně náročné na paměť zejména při regeneraci rozsáhlých slovníků. 1 GB na 2000 položek, takže na hostingu nepochodíte ani náhodou a i VPS se zapotí. Navíc ten modul nefunguje úplně spolehlivě. Pro menší menu se ale použít dá… případně si s ním jednou vygenerovat menu a pak pryč s ním.
Drupal 6.20 cache + Boost
<1% Drupal 6.20 cache + Boost (?!)
Tohle je určitě špatně… nezapomněl jste přidat potřebnou konfiguraci do .htaccess? Protože pokud Boost zafunguje, Drupal do běhu vůbec nezasáhne… Žádný bootstrap, žádný dotaz do databáze. Klientovi je pomocí pravidel v htaccess naservírován již předvygenerovaný soubor (Boost je file cache). Takže teoreticky by to mělo být rychlé téměř jako načtení HTML + nějaký ten processing Apache v htaccess.
Nedávno jsem nasazoval na jednom webu Pressflow + Boost místo Drupal + normal cache. A výsledky byly asi takovéto:
Drupal normal cache… 7req/sec
Pressflow normal cache… 9req/sec
Boost … 26req/sec (když Boost zafunguje, je jedno jestli je za ním Drupal nebo Pressflow)
Zrychlení Boostem mi tedy vyšlo cca 3× až 4×. Když vezmu vaší hodnotu Drupal normal cache 8%, tak pak by moje hodnoty byly kolem 24–32% čistého HTML. Ty čísla jsou samozřejmě individuální, budou se trochu lišit server od serveru, ale požadavek obsloužený Boostem musí být na každý pád rychlejší než Drupal + normal cache. Takže jsem si jistý, že v tom měření Boost vůbec nefungoval a servíroval se nenacachovaný obsah – ten výsledek tomu odpovídá.
Jinak na groups.drupal.org je skupina, kde se řeší běh Drupal pod Nginxem, což by mělo být ještě rychlejší, zvlášť na serverech, které jsou často pod palbou. (Nginx totiž nevytváří extra proces pro každý požadavek, tak jako Apache třeba.) Ale třeba pak zas nebude fungovat Boost – ten je stavěný jen na spolupráci s Apachem, i když IMO by stačilo přepsat ty pravidla co Boost generuje pro .htaccess a fungovalo by to s čímkoliv, ale pokud se nepletu tak nginx má nějaké cachování sám o sobě, takže by to v tomto případě asi bylo nošení dříví do lesa…
Jestli to neměřil přihlášenej
Jestli to neměřil přihlášenej jako admin (user s ID 1), myslim, že v tom případě cachování nefunguje
Boost je výbornej pro
Boost je výbornej pro anonymy – to je bez debat, zrychlení je zřejmé a funguje. Mě by spíš zajímalo řešení pro komunitní web, tzn. pro přihlášené uživatele?
to mě taky. Používám
to mě taky. Používám authcache ale výsledek neni extra znatelnej. Nepřihlášeným uživatelům běhá web parádně, okamžitě ale přihlášený uživatel..nic moc
Pak asi Memcache a nebo Varnish/Squid
Pak asi Memcache nebo Varnish/Squid. Konkrétní zkušenosti zatím nemám, ale chystám se :-)
Jo a taky cachovat bloky a
Jo a taky cachovat bloky a Views a Panels… to MÁ ZÁSADNÍ VLIV i na přihlášené uživatele…
Cachování bloků zapnutý mám a
Cachování bloků zapnutý mám a views se cachuje automaticky ne (pokud neoškrtnu na mujweb/admin/build/views/tools Disable views data caching)?
Ne. Vůbec ne. To nastavení
Ne. Vůbec ne. To nastavení jen kompletně zakazuje cachování.U Views se musí cacheování zapnout. U každého zvlášť – viz základní nastavení u každého View, položka Caching.
Views umí cachovat ve dvou úrovních – výsledky a také kompletní vyrenderovaný výsledek poskytují jen Time-based cache. Tzn nastaví se pevné časové intervaly kdy se má cache obnovit.
Ale existují na to moduly, buď cache plugin, který lze integrovat s Rules na promazávání cache a nebo plugin, kde se přímo v rozhraní Views nastaví pravidla pro reset cache.
Osobně dávám přednost programovému výmazu cache, který si řídím sám, jak chci, z vlastního custom modulu, bez megaklikadla jo jsou Rules :-)
Áha, díky za poučení,
Áha, díky za poučení, vyzkoušel sem a rozdíl je znatelnej. Ne převratnej ale de vidět, že stránka běhá svižněji.
Rules nepoužívám, snažim se používat jenom ty moduly, co potřebuju, zbytek dělat jinak takže než abych nainstaloval Rules a nastavil něco jako „vymaž data tady toho views když udělám to a to“ tak to udělám a vymažu ručně (když „to a to“ nebude nic častýho:-)) Nicméně ten plugin, s kterým by se v rozhraní views daly nastavit pravidla mě zajímá? Dá se někde stahnout? Hledal sem ale asi špatně
jasně bacha na Rules, jsou
jasně bacha na Rules, jsou strašně návykový :-]
Toto
Toto http://drupal.org/…ontent_cache
to je ono, díky. Jen by mě
to je ono, díky. Jen by mě zajímalo..mám blok pomocí views slideshow, co generuje obrázky v nodu (Tričko). Když pomocí tohodle modulu nastavit update cache při úpravě typu obsahu Tričko, vymažou se cache u všech triček jenom v tom konkrétnim nodu nebo u všech? blok je samozřejmě jeden, obsah se generuje přes argumenty
Imho sa maze cache pre ten
Imho sa maze cache pre ten view block – upravis obsah tricko → view vytiahne data vygeneruje sa zobrazenie bloku a to sa ulozi do cache.
Jinak v souvislosti s Views
Jinak v souvislosti s Views cache bacha na tohle issue: http://drupal.org/node/550962
Poslat nový komentář