Teoretických rad na téma „jak zrychlit server“ nalezneme všude dost. Horší to bývá s praktickými články, kde by lidé popisovali, co pro zrychlení udělali, proč a s jakým výsledkem. Jednu takovou „případovou zrychlovací studii“ známého českého serveru vám nabízíme.
Jestli jste někdy řešili nasazování aplikace, asi víte, že všechno odladit může být celkem zdlouhavá záležitost. Dokážete si představit, že na to máte jen týden? Že je to nemožné? Není! Jde to a ani to nemusí být příliš složité.
Reportáž z virtuální konference FOSDEM. Minule jsem popsali Go room, dnes se věnujeme monitoringu a observability.
Mikrofrontendy jsou zajímavá adaptace konceptu microservices pro potřeby frontendového vývoje. Podívejte se, co to v praxi obnáší a proč jsme se v Seznam.cz rozhodli vyvinout náš vlastní microfrontend framework, Merkur.
Webserver
Použít místo Apache nginx a memcached jako cache nějakých statických dotazů, PHP objektů a session.
Re: Webserver
Pokud běží na jediném serveru, APC funguje stejně jako memcached. (Je to ta část, které se říká user cache:
http://stackoverflow.com/questions/1965290/difference-between-user-and-system-caches-using-php-apc/
)
Díky za tip na Nginx. Stejný tip se objevil v prvním komentáři u mě na blogu, takže populárním hlasováním Nginx bude další, co vyzkoušíme. :)
Re: Webserver
Nginx je sice méně žravý a pro statický obsah i rychlejší něž Apache, ale pro spojení Apache + PHP je nejvýkonnější volbou stále Apache + mod_php.
Re: Webserver
nejvýkonnější je apache + mod_fcgid a ještě je to stabilnější
Re: Webserver
parkrat jsem s timto experimentoval a pod velkou zatezi(400 php requestu/s, staticky obsah je servirovan poolem nginxu) to rozhodne rychlejsi a stabilnejsi nez apache+mod_php nebylo.. Mate to jak podlozit? Nejake spesl nastaveni?
btw jako dobra technika pro „zrychleni webu“, napr. eshopu a jinych mene aktualizovanych webu se mi osvedcilo cachovani celych vygenerovanych stranek a jejich invalidace pri zmene dat. Vetsinou to znamena dost prace, ale vysledek stoji za to.
Re: Webserver
Já jsem APC krátce zkoušel a nepodařilo se mi ho zprovoznit, respektive jsem ho zprovoznil, ale výsledkem byly chyby při provádění skriptů, takže jsem ho opět odinstaloval.
Re: Webserver
Z moji zkusenosti:
– nejvetsi vyhoda Nginxu je, ze spotreba pameti je mnohem mensi nez u Apache a hlavne, i pro velke zateze je konstantni.
– Nginx dobre funguje v kombinaci s PHP-FPM
– APC pouzivat urcite, ale jenom jako bytecode cache. APC user cache je spise nestabilni..
– jako „user cache“ funguje asi nejlepe memcached.
– ostatni zbylou pamet pridelit cache MySQL (je jich vice druhu), cim vice tim lepe..
Re: Webserver
Zajimava alternativa nginxu je cherokee.
Vrele doporucuju se kouknout i kdyby jen pro zajimavost. Me se zdala treba webova konfigurace jako totalni silenost, ale realita je vazne takova, ze rozchodit webserver s nekolika virtualhostama, 2 konfiguracema PHPcka a uWSGI Pythonem mi trvalo asi 3 hodiny vcetne nastaveni debianu, tak abych mel Cherokee 1.3 z testingu. To musite uznat je bez predchozi zkusenosti zazrak. Nastaveni reverzni proxiny je otazka asi 5 minut.
Re: Webserver
Cherokee jsem nasadil na produkci jednoho webu, ktery pres PHP generuje nekolik desitek milionu stranek mesicne, pres den cca 9000 UIP, ale s velkym poctem opakovanych navstev, a zatim se mi jevi velmi stabilni. Administrace pres web je naprosto luxusni, vim, ze mnohy „linuxar“ nad tim ohrne ret :), ale nutno si priznat, ze nez donekonecna lezt pres SSHacko na server, editovat config a restartovat …, tak tady to mam hotove hned. Rozchodit php-fpm opet bez problemu, nastaveni pro wordpress a jina open source zverstva taktez na dve kliknuti, takze pokud to nekdo chce zkusit, vrele doporucuju … Na jinem serveru pouzivame lighttpd a taktez spokojenost, oproti Apachi se nam vyrazne zlepsila stabilita i odezvy systemu pri vetsi zatezi (napriklad sken googlem ci jinymi roboty, stahovani webu pres ruzne downloadery atd)
Ad malé odpovědi
Minifikovat před gzipem nemá smysl. gzip má rád opakující se vzory. Minifikovaný JavaScript může být po kompresi gzipem ve výsledku větší než neminifikovaný.
Dobré, je si to vyzkoušet. Zajímaostí může být, že Google Closure Compiler optimalizuje JS tak, aby gzip byl co nejúčinější.
Re: Ad malé odpovědi
Opřel jsem se o srovnání minifikátorů:
http://compressorrater.thruhere.net/
Stále ukazuje rozdíl cca deseti procentních bodů mezi minifikovaným a přirozeným gzipovaným kódem.
O vychytávce Closure Compileru jsem nevěděl, díky. Používáte ho někde naživo?
Google SPDY
Napadlo mě co zkusit Google SPDY protokol, ale nasazení by asi zabralo spoustu úsilí a přínos by viděli pouze (zatím) uživatelé Google Chrome.
Při prohlížení HTML5 databáze v prohlížeči jsem si všiml, že si tam stránky Facebooku ukládají docela dost dat (taková lepší cache?, mám uživatelovu chace na jeho pc přímo pod kontrolou) ale to se asi bude hodit jenom Facebooku a jemu podobným stránkám co načítají téměř veškerý obsah AJAXem.
Re: Google SPDY
Pomocí local storage se povedlo Hotmailu dosáhnout velice zásadního zrychlení pohybu v aplikaci. Doporučuji vyzkoušet.
Re: Google SPDY
Díky oběma za další tip. Local storage zní určitě užitečně, hlavně protože se narozdíl od cookies neposílá s požadavky.
Co si tam Facebook ukládá? (Nemám účet, podíval bych se).
Tady je knihovna, která abstrahuje od nekompatibilních a starých prohlížečů
https://github.com/marcuswestin/store.js
Re: Jak zrychlit server - několik praktických postřehů
Postrehy jsou to pekne a rad jsem si je precetl. Nevim jak to behalo predtim, kazdopadne po prokliknuti nekolika stranek to beha opravdu fajn.
Re: Jak zrychlit server - několik praktických postřehů
Děkuji, to mě těší. (Zatím nedosaženou) Metou každopádně zůstává, aby se stránka načítala na lusknutí prstů, pod desetinu sekundy. :)
Mrzí mě (pro čtenáře i pro sebe), že jsem si změny pořádně neměřil, abych věděl, jaký přínos která měla.
Pro srovnání tedy aspoň výsledky externího měření rychlosti z února 2011
http://www.webpagetest.org/result/110219_F8_Y1R/
a ze dneška
http://www.webpagetest.org/result/110727_8B_1587S/
Test probíhající z Frankfurtu ukazuje dvoj- až trojnásobné zrychlení.
Můj Firebug ukazuje zhruba něco podobného (s nižšími čísly, protože server je v Praze).
JS Async
Neřeší celé to asynchronní načítání HTML atributy defer a async?
Re: JS Async
Async je to, co Labjs využívá a co nahrazuje pro prohlížeče, které to neumí.
Kromě toho taky umožňuje explicitně specifikovat závislosti – což je u asynchronně načítaných skriptů nutné (píšu v textu).
Viz metoda $LAB.wait()
http://labjs.com/documentation.php
Implementace defer je prý nespolehlivá.
http://hacks.mozilla.org/2009/06/defer/
Re: JS Async
Paráda, díky za info, o chybném chování jsem nevěděl.
Rychlost odezvy na onclick
V pár aplikacích jsem viděl vtipně použít místo „onclick“ „onmousedown“. Je to extra jedna dvě desetinky vteřiny.
Re: Rychlost odezvy na onclick
Tak to je hardcore technika. :)
Máte pravdu, nakonec se počítá každá setina.
Na druhou stranu je dobré začít s nízko visícím ovocem, tedy tam, kde za jednotku času své práce získáte největší zrychlení.
To podle mě je databáze, cachování na serveru a cachovací hlavičky pro cachování u klienta.
Pokud se někdo dopracuje k onmousedown, klobouk dolů. :)
Re: Rychlost odezvy na onclick
Jenže pak se aplikace chová jinak, než je uživatel zvyklý — normálně totiž zmáčkne tlačítko myši (třeba nad odkazem) a může si to ještě rozmyslet (přesunout kurzor jinam a až pak pustit).
Re: Rychlost odezvy na onclick
Navíc uživatel nejčastěji používá copy a paste. Tedy když se o to pokusí, odejde na jinou stránku.
Re: Rychlost odezvy na onclick
To mi nepříjde jako optimalizace, spíš jako nepochopení významu. onmousedown se má používat ve speciálních případech. Na klikání (tj. stisk a uvolnění tlačítka) reaguje onclick a to v souladu s chováním OS.
onmousedown by se mělo používat na akce, jejichž spuštění modifikuje pouze zobrazení, ale neprovádí žádný „zásah do dat“.
Třeba přepnutí záložky (tabu), zobrazení menu, tam se použití onmousedown přímo vybízí, kdežto jakékoliv tlačítko typu uložit, odeslat by mělo reagovat až na celý klik.
Re: Rychlost odezvy na onclick
+1 přesně tak
Re: Rychlost odezvy na onclick
Zajímavé, ale mění to trošku ovládání, byť ne až tak závratně. Ale nevím, jak se s tím vypořádá které dotykové zařízení – jestli nějaké nespustí nějakou akci již při doteku, když uživatel chtěl rolovat nebo zobrazit kontextové menu.
Obecně bych se snažil takovýmto změnám pokud možno vyhýbat, pokud neladíme pro konkrétní zařízení například do firemního prostředí, protože nepatrné zrychlení by mohlo bý’t vykoupeno nepříjemnými problémy, zvláště (ale nejen) u uživatelů se specifickým prostředím a/nebo specifickými návyky.
Re: Rychlost odezvy na onclick
Používá to například gmail u „hvězdičkování“ mailů, tedy tam, kde většinou nemůže dojít k nějakému závratnému omylu při „ukliknutí“.
Re: Rychlost odezvy na onclick
Nebo ještě třeba při otevírání mailů.
co treba vygenerovat nektere stranky jako staticke?
Hodne staticke nemenne stranky vygenerovat komplet a pak je predhazovat, nasledne je updateovat jen kdyz dojde ke zmene informaci nanich, typicky zrovna vstupni stranky fora, stranky pod polozkami horniho menu. je treba je updateovat jen kvuli statistikam na prave strane.
Re: co treba vygenerovat nektere stranky jako staticke?
vítejte v roce 1998
Re: co treba vygenerovat nektere stranky jako staticke?
Viď? Tak starý princip, na který pak na nějakých deset let vývojářský mainstream radostně zapomněl, opojen skriptovacími jazyky a databázemi, a teď ho znovuobjevuje.
JSMin
Já už léta používám na minimalizaci JavaScriptu web http://fmarcia.info/jsmin/test.html a když je kód dobře napsaný (středníky za objektem var foo = {}; apod.), tak funguje dobře :-)
keep alive
Mám web, kde je na titulní stránce hodně obrázků. Řekl bych typická situace pro uplatnění KeepAlive.
Jakmile ho ale zapnu, načítání se vyhoupne třeba k deseti vteřinám a tak polovina obrázků se vůbec nenačte. V Chrome vidím, že tyto chybějící mají dlouhou dobu načítání, jejich mimetyp je zobrazován application/octet-stream (jinak je správně) a v podrobnostech nejsou vidět hlavičky odpovědi.
Jakmile KA vypnu, vejdu se do dvou sekund (žádná sláva, vím) a vše se načítá v pořádku, jsou správně mimetypy i hlavičky.
Vůbec už netuším kde hledat vysvětlení. V apache2.conf klidně nastavím timeout i keepalive timeout na vysoké hodnoty, apache restartuji (gracefull) a nemá to na tenhle problém efekt.
Percona server
Zaujímavá možnosť zrýchlenia MySQL je popísaná tu:
http://newsletter.websupport.sk/4.htm#dd
http://www.percona.com/software/percona-server/benchmarks/