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.cz
http://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.cz
http://www.webpagetest.org/result/110219_QK_Y28/
vypnuto keep-alive

www.interval.cz
http://www.webpagetest.org/result/110219_6Z_Y2D/
vypnuto cachování a komprese

www.h1.cz
http://www.webpagetest.org/result/110219_3Q_Y2H/
nezvládnuté cachování

www.ataxo.cz
http://www.webpagetest.org/result/110219_ES_Y30/
vypnutá komprese, nezvládnuté cachování

www.builder.cz
http://www.webpagetest.org/result/110219_3Y_Y34/
vypnutá komprese, keep-alive i cachování -- zřejmě slušnej oddíl!

404m.com
http://www.webpagetest.org/result/110219_B4_Y3F/
vypnutá komprese, vypnuté cachování

www.fandor.cz
http://www.webpagetest.org/result/110219_TS_Y3P/
vypnuta komprese, keep-alive i cachování

ranky.cz
http://www.webpagetest.org/result/110219_SR_Y3X/
vypnuta komprese, vypnuto cachování

www.tvorba-webu.cz
http://www.webpagetest.org/result/110219_3Z_Y41/
vypnuto cachování

www.vrana.cz
http://www.webpagetest.org/result/110219_47_Y46/
vypnutá komprese, vypnuto cachování

programujte.com
http://www.webpagetest.org/result/110219_NV_Y3Z/
vypnuta komprese i cachování

www.blabolnik.cz
http://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?

Původně odeslal igor

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-sp...les_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.html

Ně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ázek
http://www.novinky.cz/static/images/logo.gif ,
dotyčný server odpoví mimo jiné:

Expires: Sun, 20 Feb 2011 11:23:58 GMT

Cache-Control: max-age=86400

Takž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ázek
http://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 GMT
ETag: "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 GMT
If-None-Match: "3f1872c-d1a-483e6948fa040"

a server pro každý objekt odpoví, že je stále platný:

HTTP/1.1 304 Not Modified
Date: Sat, 19 Feb 2011 11:35:19 GMT
Server: Apache/2.2.3 (CentOS)
Connection: close
ETag: "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 sebe


5) 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ísto
http://webtrh.cz/images/webtrh-logo-transparent-45.gif

bychom tak mohli GIFy stahovat z URL typu
http://gif.webtrh.cz/images/webtrh-l...sparent-45.gif


7) 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/w...sparent-45.gif

a 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/

Původně odeslal petrx

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

Původně odeslal vdusek

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

Původně odeslal Michal Kubíček

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/11..._optimization/

---------- Příspěvek doplněn 19.02.2011 v 19:53 ----------

Původně odeslal toshi

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

Původně odeslal petrx

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

Původně odeslal toshi

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

Původně odeslal Martin Schlemmer

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

1. na tom samém serveru běží několik dalších webů, nejen mojich - "defaultně" něco zapínat by nedopadlo dobře, ostatně můžeme se zamyslet proč apache defaultně ani jednu z možností zapnutou nemá

2. nemohu a nechci gzipovat celý web - speciálně data z ranky.cz načítají skripty, které si z gzipem nemusí umět poradit (ostatně hádejte o co jde tu http://webtrh.cz/122094-zpracovani-url-obrazku) - mohu kompresovat část, ale není důvod proč udržovat další kód - není to content heavy web a je mi upřímně jedno jestli se někomu načítá o pět milisekund déle

3. cachovat bych mohl lecos, ale jednak by byl výsledný efekt mizivý, jednak se mi nevyplatí tím zabývat (což je případ naprosté většiny uvedených webů) a jednak poměrně často zasahuju do kódu, čímž by narůstala práce (třeba v případě předkomprimovaných souborů) a vesměs i řešení dalších chyb.

Nastavení cache/gzip je individuální záležitost každého webu, je zhovadilost obviňovat administrátory/hostingy.

Původně odeslal toshi

1. na tom samém serveru běží několik dalších webů, nejen mojich - "defaultně" něco zapínat by nedopadlo dobře, ostatně můžeme se zamyslet proč apache defaultně ani jednu z možností zapnutou nemá

2. nemohu a nechci gzipovat celý web - speciálně data z ranky.cz načítají skripty, které si z gzipem nemusí umět poradit (ostatně hádejte o co jde tu http://webtrh.cz/122094-zpracovani-url-obrazku) - mohu kompresovat část, ale není důvod proč udržovat další kód - není to content heavy web a je mi upřímně jedno jestli se někomu načítá o pět milisekund déle

3. cachovat bych mohl lecos, ale jednak by byl výsledný efekt mizivý, jednak se mi nevyplatí tím zabývat (což je případ naprosté většiny uvedených webů) a jednak poměrně často zasahuju do kódu, čímž by narůstala práce (třeba v případě předkomprimovaných souborů) a vesměs i řešení dalších chyb.

Nastavení cache/gzip je individuální záležitost každého webu, je zhovadilost obviňovat administrátory/hostingy.

1. Pokud bys defaultně zapnul kompresi, pomůžeš i ostatním webům.

2. HTTP komprese je z hlediska klienta celkem transparentní, fopen / curl s ní nemají problém. Komprese on-the-fly funguje i u dynamicky generovaného obsahu

3. Předkomprimované soubory jsou opravdu pakárna, chce to kompresi on-the-fly. Kvalitní administrátor by to věděl.

když myslíš...

Hmmm, petrx na sebe minimálně upozornil - jeho příspěvek vzbudil pozornost.

Hodnotit kvalitu administrátorů/správců pouze na základě http://www.webpagetest.org/ je HODNĚ diskutabilní

Původně odeslal vdusek

Hmmm, petrx na sebe minimálně upozornil - jeho příspěvek vzbudil pozornost.

Hodnotit kvalitu administrátorů/správců pouze na základě http://www.webpagetest.org/ je HODNĚ diskutabilní

Neříkám, že hodnotím kvalitu adminů "pouze" na základě webpagetest.org

O adminovi hodně vypovídají i jeho nameservery. A další věci.

Takže pokud někdo používá děravé nameservery:
http://recursive.iana.org/?query=builder.cz
a ještě na společném segmentu sítě, je to prostě nemehlo.

Může existovat nekvalitní webhosting, který má keep-alive atd. nastaveno dobře

Ale nemůže existovat kvalitní hosting, pokud má keep-alive, DNS apod. nastaveno špatně.

Nekvalitním hostingům a adminům je třeba udělat pápá.

A koupit jim učebnici o TCP/IP a souvisejících protokolech.

Mimochodem takové lehčí shrnutí pro programátory je na http://docs.symfony-reloaded.org/guides/cache/http.html

Původně odeslal toshi

Mimochodem takové lehčí shrnutí pro programátory je na http://docs.symfony-reloaded.org/guides/cache/http.html

No ano, cituji:

"... the less you do in your application to return a 304 response, the better."

Zajímavé srovnání, ale myslím, že nijak významně vypovídající.

Za Programujte.com:
Jak již zde napsal toshi, některá nastavení jsou cílená.
Například cachování ve většině případů vyplé mít musíme (cachujeme obsah na serveru; velikost dat to neovlivní, ale výkon ano) a kompresi jsme kvůli jistým nástrojům museli mít vyplou také (ač si s tím nadále hrajeme a nakonec ji časem asi zavedeme).

Díváš se na to z pohledu statisckého webu, což je chyba. Plošně říct: "necachujete, nekomprimujete, jste lotři" je, minimálně, zbytečné.

Původně odeslal Curo

Zajímavé srovnání, ale myslím, že nijak významně vypovídající.

Za Programujte.com:
Jak již zde napsal toshi, některá nastavení jsou cílená.
Například cachování ve většině případů vyplé mít musíme (cachujeme obsah na serveru; velikost dat to neovlivní, ale výkon ano) a kompresi jsme kvůli jistým nástrojům museli mít vyplou také (ač si s tím nadále hrajeme a nakonec ji časem asi zavedeme).

Díváš se na to z pohledu statisckého webu, což je chyba. Plošně říct: "necachujete, nekomprimujete, jste lotři" je, minimálně, zbytečné.

Já se samozřejmě v praxi zabývám převážně dynamicky generovanými weby.

A když jsme u toho:

Copak
http://programujte.com/lightbox.js

http://programujte.com/img/pozadi_tmave.gif

apod. nejsou statické objekty?

A copak nelze
http://programujte.com/
i
http://programujte.com/lightbox.js
komprimovat on-the-fly?

A proč se vlastně lightbox.js nestahuje z aliasu typu http://js.programujte.com/lightbox.js a proč se http://programujte.com/img/pozadi_tmave.gif nestahuje z aliasu typu http://gif.programujte.com/img/pozadi_tmave.gif ?

Browser tahá z 1 hostname např. pouze 2 TCP spojení, takže HTTP objekty je nutno rozdělit mezi více hostnames.

Na druhou stranu je pravda, že za necachované obrázky může websnapr.com, takže s tím moc nenaděláš.

Ovšem největším průserem je doba generování homepage (teprve po uplynutí 2.1 sekundy od HTTP requestu začne server odpovídat -- něco máš v CMS hrozně špatně, asi by pomohlo odladit SQL dotazy nebo aspoň uvnitř CMS cachovat fragmenty HTML)

Já se samozřejmě v praxi zabývám převážně dynamicky generovanými weby.
Netvrdil jsem opak.

Na vše odpovím vcelku jednoduše: protože rok 2005.
Některé věci, jako komprimace celé stránky, nejsou možné díky některým nástrojům, které používáme (nadále nebudeme, proto jsem psal, že komprimaci časem zavedeme).

Původně odeslal Curo

Já se samozřejmě v praxi zabývám převážně dynamicky generovanými weby.
Netvrdil jsem opak.

Na vše odpovím vcelku jednoduše: protože rok 2005.
Některé věci, jako komprimace celé stránky, nejsou možné díky některým nástrojům, které používáme (nadále nebudeme, proto jsem psal, že komprimaci časem zavedeme).

1) Tyhle věci platily i v roce 2005

2) Komprese se dá vyřešit servírováním webu en bloc pomocí CloudFlare.com

1) Tyhle věci platily i v roce 2005
Já byl v té době náctiletý, na střední škole, s povinnou znalostí němčiny a zdrojů na toto téma, které by mě zasáhly, nebylo tolik, jako v dnešní době - ať to zní jakkoliv úsměvně. Můj argument tedy nebyl směřován na technickou úroveň tehdejší doby.

Produkty třetí strany podobného typu zatím zavádět nechceme.

Původně odeslal Curo

1) Tyhle věci platily i v roce 2005
Já byl v té době náctiletý, na střední škole, s povinnou znalostí němčiny a zdrojů na toto téma, které by mě zasáhly, nebylo tolik, jako v dnešní době - ať to zní jakkoliv úsměvně. Můj argument tedy nebyl směřován na technickou úroveň tehdejší doby.

Produkty třetí strany podobného typu zatím zavádět nechceme.

== "Byl jsem amatér tehdy, jsem amatér nyní"

Takže jsem měl pravdu, lidé opravdu neumějí dobře nakonfigurovat webserver.

Koukám opět plodná diskuze, tak já se zase loučím.

petrx - byl jsi profesionál tehdy, jsi profesionál nyní

Bez znalosti souvislostí nelze vydávat jednoznačné závěry a doporučení.
S něčím s tebou lze souhlasit, ale vůbec se mi nelíbí se způsob, jakým to prezentuješ

-1

PS - to téma vypadalo na začátku zajímavě, ale trochu se to zvrtlo v osobní útoky