Zvláštní: Lidé neumějí nakonfigurovat webserver

Udělal jsem si malý průzkum, jak dobře jsou nastaveny webservery u renomovaných webů, které se zabývají web developmentem a podnikáním na Internetu.Výsledky jsou tristní, přestože zpravidla administrátor nastaví špatně jen část parametrů:Webtrh.czhttp://www.webpagetest.org/result/110219_F8_Y1R/vypnuto keep-alive (=> pomalejší načítání), vypnuté cachování statického obsahu (=> pomalé načítání při opakované návštěvě stránky, prohlížeč se vždy ptá serveru, zda se objekt nezměnil)www.jakpsatweb.czhttp://www.webpagetest.org/result/110219_QK_Y28/vypnuto keep-alivewww.interval.czhttp://www.webpagetest.org/result/110219_6Z_Y2D/vypnuto cachování a kompresewww.h1.czhttp://www.webpagetest.org/result/110219_3Q_Y2H/nezvládnuté cachováníwww.ataxo.czhttp://www.webpagetest.org/result/110219_ES_Y30/vypnutá komprese, nezvládnuté cachováníwww.builder.czhttp://www.webpagetest.org/result/110219_3Y_Y34/vypnutá komprese, keep-alive i cachování -- zřejmě slušnej oddíl!404m.comhttp://www.webpagetest.org/result/110219_B4_Y3F/vypnutá komprese, vypnuté cachováníwww.fandor.czhttp://www.webpagetest.org/result/110219_TS_Y3P/vypnuta komprese, keep-alive i cachováníranky.czhttp://www.webpagetest.org/result/110219_SR_Y3X/vypnuta komprese, vypnuto cachováníwww.tvorba-webu.czhttp://www.webpagetest.org/result/110219_3Z_Y41/vypnuto cachováníwww.vrana.czhttp://www.webpagetest.org/result/110219_47_Y46/vypnutá komprese, vypnuto cachováníprogramujte.comhttp://www.webpagetest.org/result/110219_NV_Y3Z/vypnuta komprese i cachováníwww.blabolnik.czhttp://www.webpagetest.org/result/110219_JW_Y4Y/vypnuta komprese, vypnuto cachováníProč je kvalita administrátorů tak nízká?

V tomto som uplny laik, takze sa ospravedlnujem za laicky komentar: My sme napriklad na serveri (silver.ag) ziadali vypnut kompresiu pretoze aj pri 1% kompresii kvalita obrazkov prudko poklesla (technicky narocne fotky). Moze to mat nieco spolocne s Vasimi zisteniami?

Napsal igor;627022

V tomto som uplny laik, takze sa ospravedlnujem za laicky komentar:

My sme napriklad na serveri (silver.ag) ziadali vypnut kompresiu pretoze aj pri 1% kompresii kvalita obrazkov prudko poklesla (technicky narocne fotky). Moze to mat nieco spolocne s Vasimi zisteniami?

JPEG v sobě obsahuje ztrátovou kompresi pomocí diskrétní kosinové transformace (DCT)Já jsem však měl na mysli HTTP kompresi, kdy se data transparentně zkomprimují na serveru metodou gzip či deflate a do browseru se stáhne identický soubor.Díval jsem se na www.silver.ag a ten webhosting je dost hrozný:http://www.webpagetest.org/result/110219_55_Y5D/-- vypnuto keep-alive, vypnuta komprese textů, vypnuto cachování

Díky za upozornění na Webtrh. Pro ostatní, dobré zdroje jsou tady http://code.google.com/speed/page-speed/docs/rules_intro.html a http://developer.yahoo.com/performance/rules.html Ke Keep-Alive je potřeba dodat, že u HTTP/1.1 jsou všechna spojení defaultně persistentní.

2petrx: mohl byste se trosku vice rozepsat o idelanim nastaveni atd.? myslim, ze by to tu urcite vice lidi ocenilo

1) Persistentní spojení:Protokol HTTP 1.1 (starý 14 let...) zavedl, že po uspokojení HTTP requestu klienta webserver nezavře TCP spojení, ale ještě chvilku čeká, zda klient nepošle žádost o další HTTP objekt (např. obrázek na webové stránce)Ušetří se tak režie s navazováním nového TCP spojení a také se použije již vytvořené TCP window (určitě jste si všimli, že když stahujete velký soubor po Internetu, stahuje se nejprve pomalu a postupně zrychlí; toto zrychlení se v případě persistentních spojení "recykluje" i pro následující HTTP objekty)Něco k TCP window:http://www.cpress.cz/knihy/tcp-ip-bezp/cd-0x/9.htmlNěkteří správci serverů se domnívají, že chvíli "visící" TCP spojení snižuje výkon webserveru. Ve skutečnosti se díky persistentnímu TCP spojení přenese obsah stránky ke klientu rychleji, takže spojení TCP paradoxně trvá kratší dobu i při započteném "visení". Méně sofistikovaní správci serverů proto často vypínají keep-alive v iluzi, že tím šetří výkon.Na Webtrhu nyní běží zastaralý protokol HTTP 1.0 (který keep-alive prostě neumí), důvod neznám.2) Komprese textu:Nejen (X)HTML, ale i CSS, JavaScript, RSS apod. jsou textové formáty. To má spoustu výhod (čitelnost, parsování, debugování...), odvrácenou stranou je relativně velký objem dat. Problém je možno z velké části vyřešit zapnutím HTTP komprese => text se na serveru zkomprimuje algoritmem gzip nebo deflate, browser si jej rozbalí a totožná data se tak přenesou rychleji.Někteří administrátoři se domnívají, že komprimovat data je zbytečné (ujišťuji je, že zejména u velkých javascriptových knihoven nebo rozsáhlých CSS to zbytečné není) nebo že to zatěžuje server (jedná se však o výpočetně a paměťově nenáročné operace)3) Komprese obrázků:Obrázkové formáty GIF, JPG, PNG obsahují kompresi přímo ve formátu dat, teoreticky by nebylo nutné je dále komprimovat. Může se však stát, že někdo například uloží GIF / PNG s větším počtem bitplanes, než by odpovídalo počtu jediněčných barev. Nebo uloží JPG extrémně neefektivně.Ukazuje se, že k těmto jevům ochází u BFU u profesionálních grafiků, takže má smysl zapnout HTTP kompresi i pro obrázky.Dalším levelem je práce s kompresí na aplikační úrovni (velikost palety u GIF/PNG, kombinace kompresních parametrů u JPG/PNG), to však již není řešitelné administrátorem.4) Cache static content:Pokud klient požádá např. o obrázekhttp://www.novinky.cz/static/images/logo.gif ,dotyčný server odpoví mimo jiné:Expires: Sun, 20 Feb 2011 11:23:58 GMTCache-Control: max-age=86400Takže browser ví, že nějakou dobu bude platit obrázek uložený ve vyrovnávací paměti.Pokud si však browser stáhne obrázekhttp://webtrh.cz/images/webtrh-logo-transparent-45.gif ,server Webtrhu v odpovědi neuvede údaj Expires: ani Cache-Control: a místo toho vrací:Last-Modified: Sat, 10 Apr 2010 19:04:25 GMTETag: "3f1872c-d1a-483e6948fa040"Při každé návštěvě kterékoli stránky na Webtrhu se pak klient vždy zeptá na všechny objekty, které má ve vyrovnávací paměti, dotazy obsahují toto:If-Modified-Since: Sat, 10 Apr 2010 19:04:25 GMTIf-None-Match: "3f1872c-d1a-483e6948fa040"a server pro každý objekt odpoví, že je stále platný:HTTP/1.1 304 Not ModifiedDate: Sat, 19 Feb 2011 11:35:19 GMTServer: Apache/2.2.3 (CentOS)Connection: closeETag: "3f1872c-d1a-483e6948fa040"Webtrh i ostatní servery s nezvládnutým cachováním tak pomocí klientských browserů v podstatě páchají DDoS samy na sebe5) Kombinovat soubory CSS a JS:Je výhodnější snížit počet souborů s CSS a s JavaScriptem na minimum, tj. sesadit jednotlivé styly a skripty dohromady, např. do 1 souboru pro CSS a do 1 souboru pro JavaScript.6) Paralelní stahování:Některé browsery jsou ochotné stahovat obsah jen po 2 TCP spojeních z 1 hostname. Takže i když je zapnuto keep-alive, HTTP objekty se načítají sekvenčně, "husím pochodem" za sebou. Pokud stránka obsahuje více různých souborů, může být výhodnější je stahovat paralelně. Toho se dá dosáhnout např. vytvořením aliasů a stahováním souborů z aliasů dle přípony souboru.Místohttp://webtrh.cz/images/webtrh-logo-transparent-45.gifbychom tak mohli GIFy stahovat z URL typu http://gif.webtrh.cz/images/webtrh-logo-transparent-45.gif7) Content delivery network:Statický obsah je možno servírovat přes content delivery network. Ta buď nabízí API pro stěhování souborů do cloudu, nebo může fungovat jako reverzní proxy cache, což je často výhodnější.Pro začátek je možno zkusit přestěhovat statický obsah na aliasy v jiné, servisní doméně, např.http://gif.webtrh-static.cz/images/webtrh-logo-transparent-45.gifa servisní doménu nechat obhospodařovat pomocí reverzní proxy cache www.cloudflare.com (ta je, mimochodem, schopna rovnou řešit i cachování, kompresi a keep-alive i pro homepage webu a zároveň se snaží filtrovat útoky, což je někdy užitečné).Nebo si můžete na vlastním serveru spustit Varnish + nginx (samotná reverzní proxy cache Varnish zatím neumí kompresi, takže je zapotřebí nginx jako front-end)8) Počáteční velikost TCP window:Některé firmy, např. Google, zrychlují své stránky tím, že na serveru napevno nastaví větší počáteční velikost TCP window.Námět pro pokročilé.

A není trochu větší problém, že mnoho hostingů jede přes nezabezpečené protokoly FTP, IMAP, POP3, administraci má jen přes HTTP?Jak hodně jsou důvěryhodné špatně používané certifikáty, kdy neodpovídá jméno serveru údajům v certifikátu a nebo se používají tzv. divoké certifikáty?Osobně bych raději řešil dříve bezpečnost, než výkon.Raději mít data v bezpečí, než je za každou cenu rychle zpracovávat

mám pochválit soudruha z TELE3? http://www.webpagetest.org/result/110219_D6_Z2K/

Napsal petrx;627021

Proč je kvalita administrátorů tak nízká?

To, že mám na ranky.cz vypnuté cachování a kompresi značí, že moje kvality jsou nízké? Co když je to třeba schválně? Ty tvoje závěry jsou vícenež hloupé.

Napsal vdusek;627117

A není trochu větší problém, že mnoho hostingů jede přes nezabezpečené protokoly FTP, IMAP, POP3, administraci má jen přes HTTP?

Jak hodně jsou důvěryhodné špatně používané certifikáty, kdy neodpovídá jméno serveru údajům v certifikátu a nebo se používají tzv. divoké certifikáty?

Osobně bych raději řešil dříve bezpečnost, než výkon.

Raději mít data v bezpečí, než je za každou cenu rychle zpracovávat

Není problém používat pro administraci webu www.example.com URL typu https://admin.example.com

Díky petrovi za pěkné shrnutí, možná by to stálo i za nějaký článek s obecnými radami pro adminy ;)

Napsal Michal Kubíček;627139

mám pochválit soudruha z TELE3? http://www.webpagetest.org/result/110219_D6_Z2K/

Je třeba se více snažit: http://www.webpagetest.org/result/110219_D6_Z2K/1/performance_optimization/ ---------- Příspěvek doplněn 19.02.2011 v 19:53 ----------

Napsal toshi;627148

To, že mám na ranky.cz vypnuté cachování a kompresi značí, že moje kvality jsou nízké? Co když je to třeba schválně? Ty tvoje závěry jsou vícenež hloupé.

Znamená to, že je nízká kvalita tvého administrátora a/nebo tvého hostingu. Pomalost webu je otravná pro lidi a Google ji penalizuje Podívej se do statistik svého webu v Google Webmaster Tools

Napsal petrx;627185

Znamená to, že je nízká kvalita tvého administrátora a/nebo tvého hostingu.

Ne. Píšu po druhé - cachování a komprese je vypnuté naprosto schválně. Pokud by si se pohyboval mimo teorii taky v praxi tak bys třeba možná i přišel na to proč. (a spravuji si servery sám, díky)

Proč máš záměrně vypnutou kompresi (on-the-fly, máš i něco proti předkomprimovaným souborům?) a cachovací hlavičky (předpokládám, že mluvíme o Expires a Cache-Control)?

Napsal toshi;627188

Ne. Píšu po druhé - cachování a komprese je vypnuté naprosto schválně. Pokud by si se pohyboval mimo teorii taky v praxi tak bys třeba možná i přišel na to proč. (a spravuji si servery sám, díky)

Cachování máš možná vypnuté proto, že při změně obsahu CSS, JS nebo obrázku neumíš změnit URL nového souboru (nebo tě to nenapadlo)Kompresi máš možná vypnutou proto, že se domníváš, že tím ušetříš výkon. Zkus se někdy zamyslet, kolik systémových zdrojů spotřebuje jaká operace. Nápověda: Operace s malými celými čísly jsou více v pohodě než online komunikace s čekáním na odezvy protistrany, takže dohromady je jednodušší si poměrně jednodušše data zkomprimovat (v RAM, potažmo v L2/L3 cache) a pak jich poslat méně, v menším množsví paketů.