34 komentářů k článku Jak zrychlit server – několik praktických postřehů:

  1. napalm

    Webserver

    Použít místo Apache nginx a memcached jako cache nějakých statických dotazů, PHP objektů a session.

      1. Dundee5

        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.

          1. cita

            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.

      2. napalm

        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.

      3. jlx

        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..

    1. Jerry12

      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.

      1. Ferda Mravenec

        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)

  2. Aleš Roubíček

    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ší.

    1. Martin

      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?

  3. knapek.mojeid.cz

    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.

    1. Aleš Roubíček

      Re: Google SPDY

      Pomocí local storage se povedlo Hotmailu dosáhnout velice zásadního zrychlení pohybu v aplikaci. Doporučuji vyzkoušet.

      1. Martin

        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

  4. mekele

    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.

    1. Martin

      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).

  5. jiridobry

    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.

    1. Martin

      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ů. :)

      1. Franta

        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).

        1. Tin

          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.

      2. langpa

        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.

    2. v6ak

      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.

      1. jiridobry

        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í“.

  6. Oldis

    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.

      1. Martin Malý

        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.

  7. www.google.com

    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.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3522