abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 18:55 | Zajímavý projekt

Společnosti Google, Microsoft, Twitter a Facebook společně představily open source platformu Data Transfer Project (DTP). Cílem platformy je zjednodušit uživatelům přechod a přenos dat mezi jednotlivými online službami. Podrobnosti v pdf a na GitHubu.

Ladislav Hagara | Komentářů: 1
včera 18:33 | Nová verze

Canonical a Microsoft společně oznámili, že PowerShell Core je nově dostupný také jako snap balíček na Snapcraftu. Microsoft uvolnil zdrojové kódy PowerShellu (Wikipedie, GitHub) v srpnu 2016 pod open source licencí MIT a naportoval je na Linux.

Ladislav Hagara | Komentářů: 1
včera 13:11 | Zajímavý projekt

Novinkou v minor aktualizaci webového prohlížeče Vivaldi je podpora vyhledávače Qwant (Wikipedie). Vývojáři Vivaldi zdůrazňují, že se jedná o evropský vyhledávač respektující soukromí uživatelů.

Ladislav Hagara | Komentářů: 6
včera 01:33 | Nová verze

Po šesti letech od vydání verze 1.0 byla vydána verze 2.0 multiplatformního editoru tagů MusicBrainz Picard (Wikipedie). Přehled novinek, vylepšení a oprav v changelogu.

Ladislav Hagara | Komentářů: 0
19.7. 16:22 | Nová verze Ladislav Hagara | Komentářů: 11
19.7. 15:00 | Komunita

Dnes končí podpora Ubuntu 17.10 Artful Aardvark. Uživatelům je doporučen přechod na Ubuntu 18.04 Bionic Beaver s prodlouženou podporou do roku 2023. Podpora standardních verzí Ubuntu je 9 měsíců. Verze 17.10 byla vydána 19. října 2017.

Ladislav Hagara | Komentářů: 11
19.7. 13:33 | Bezpečnostní upozornění

Společnost Oracle vydala čtvrtletní bezpečnostní aktualizaci svých softwarových produktů (CPU, Critical Patch Update). Opraveno bylo celkově 334 bezpečnostních chyb. V Oracle Java SE je například opraveno 8 bezpečnostních chyb. Všechny jsou vzdáleně zneužitelné bez autentizace. V Oracle MySQL je opraveno 31 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 7 z nich.

Ladislav Hagara | Komentářů: 0
19.7. 13:11 | Zajímavý software

Nick Clifton zveřejnil na blogu společnosti Red Hat věnujícímu se počítačové bezpečnosti nástroj, pomocí kterého lze ověřit, zda jsou binární spustitelné soubory odolné vůči variantě 1 bezpečnostní chyby Spectre v procesorech.

Ladislav Hagara | Komentářů: 0
19.7. 03:00 | Nová verze

Po více než roce vývoje od vydání verze 1.12 byla vydána nová verze 1.13 Java edice počítačové hry Minecraft (Wikipedie). Kódový název nejnovější verze je Update Aquatic. Přehled novinek v oficiálním oznámení o vydání. Detailní přehled novinek na Gamepedii a na YouTube.

Ladislav Hagara | Komentářů: 4
18.7. 23:55 | Nová verze

Společnost Epic Games vydala verzi 4.20 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Přehled novinek i s celou řadou obrázků a videi v oznámení na blogu.

Ladislav Hagara | Komentářů: 0
Jak čtete delší texty z webových stránek?
 (77%)
 (20%)
 (5%)
 (7%)
 (2%)
 (10%)
Celkem 371 hlasů
 Komentářů: 40, poslední 29.6. 10:21
    Rozcestník

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

    8.8.2017 12:56 Kit | skóre: 41 | Brno
    Používání cache na HTTP serverech
    Přečteno: 675×
    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?
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.

    Odpovědi

    Josef Kufner avatar 8.8.2017 14:08 Josef Kufner | skóre: 68
    Rozbalit Rozbalit vše Re: Používání cache na HTTP serverech
    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).
    Hello world ! Segmentation fault (core dumped)
    8.8.2017 19:23 Kit | skóre: 41 | Brno
    Rozbalit Rozbalit vše Re: Používání cache na HTTP serverech
    Díky za inspirující seznam generátorů. Některý z nich se mi určitě bude hodit alespoň jako polotovar.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    10.8.2017 00:15 Petr
    Rozbalit Rozbalit vše Re: Používání cache na HTTP serverech
    A co kvalita? Treba typos? Zadny review proces? Davat veci rovnou do produkce z gitu je mozna rychle, ale bez zaruky kvality.
    Josef Kufner avatar 10.8.2017 00:45 Josef Kufner | skóre: 68
    Rozbalit Rozbalit vše Re: Používání cache na HTTP serverech
    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).
    Hello world ! Segmentation fault (core dumped)
    Josef Kufner avatar 8.8.2017 14:20 Josef Kufner | skóre: 68
    Rozbalit Rozbalit vše Re: Používání cache na HTTP serverech
    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).
    Hello world ! Segmentation fault (core dumped)
    9.8.2017 21:38 Kit | skóre: 41 | Brno
    Rozbalit Rozbalit vše Re: Používání cache na HTTP serverech
    • 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
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    Josef Kufner avatar 10.8.2017 00:04 Josef Kufner | skóre: 68
    Rozbalit Rozbalit vše Re: Používání cache na HTTP serverech
    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.
    Hello world ! Segmentation fault (core dumped)
    9.8.2017 22:40 Sten
    Rozbalit Rozbalit vše Re: Používání cache na HTTP serverech
    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 avatar 10.8.2017 00:30 Josef Kufner | skóre: 68
    Rozbalit Rozbalit vše Re: Používání cache na HTTP serverech
    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é.
    Hello world ! Segmentation fault (core dumped)
    11.8.2017 00:14 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Používání cache na HTTP serverech
    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í.
    Quando omni flunkus moritati
    10.8.2017 00:42 Kit | skóre: 41 | Brno
    Rozbalit Rozbalit vše Re: Používání cache na HTTP serverech
    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.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    10.8.2017 09:18 MP
    Rozbalit Rozbalit vše Re: Používání cache na HTTP serverech
    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.
    10.8.2017 10:34 Kit | skóre: 41 | Brno
    Rozbalit Rozbalit vše Re: Používání cache na HTTP serverech
    Když databáze používá engine MEMORY, tak se cache nedělá - byla by zbytečná.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    11.8.2017 10:31 MP
    Rozbalit Rozbalit vše Re: Používání cache na HTTP serverech
    To neznam, ale muze to tak byt. Jenze v pripade databaze stale musite resit funkcionalitu z hlediska HA.
    11.8.2017 12:26 Kit | skóre: 41 | Brno
    Rozbalit Rozbalit vše Re: Používání cache na HTTP serverech
    Neřeší to náhodou databáze sama?
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    8.8.2017 17:46 cronin | skóre: 49
    Rozbalit Rozbalit vše Re: Používání cache na HTTP serverech
    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.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.