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

25. 2. 2011 11:05:58

Jak jsem uvedl, chtěl jsem přesunout statický obsah na smostatná hostnames (a ideálně na CDN) -- narazilo na odpor vývojářů / administrátorů

Chtěl jsem také zkonsolidovat CSS do jediného souboru a JavaScript do jediného souboru (kromě samostatného trackovacího scriptu pro Google Analytics) -- narazilo na odpor vývojářů / administrátorů

Takže rychlost webu stále není optimální, na druhou stranu je krásně vidět, jak se web krásně zrychlí i čistě jen opravou nastavení webserveru.

Podívám se, zda mám někde uloženo více výsledků z jednotlivých fází.

Obecně lze říci, že přínos keep-alive a komprese je srovnatelný a že korektně nastavené cachování zrychlí opakované načtení stránek několikanásobně.

Vzhledem k tomu, že lidé většinou navštěvují postupně různé stránky webu, které sdílejí společné statické objekty (CSS, JavaScript, ikonky, loga...), asi by bylo nejvýhodnější začít s korektním nastavením cachování.

Paradoxně zrovna cachování bývá nejčastěji nastaveno úplně špatně.

*****

Pro inspiraci pár webů, které jsou nakonfigurovány relativně dobře:

www.google.com

http://www.webpagetest.org/result/110225_JF_226D/

www.facebook.com

http://www.webpagetest.org/result/110225_FC_225V/

www.linkedin.com

http://www.webpagetest.org/result/110225_3J_225F/

maps.google.com

http://www.webpagetest.org/result/110225_TY_2256/

www.bing.com

http://www.webpagetest.org/result/110225_7E_226H/

maps.bing.com

http://www.webpagetest.org/result/110225_QP_2289/

---------- Příspěvek doplněn 25.02.2011 v 22:25 ----------

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

Haha, nejdřív se do mě toshi naváží a pak stejně zapne kompresi i cachování.

Původní stav:

http://www.webpagetest.org/result/110219_SR_Y3X/

Nynější stav, web se načítá rychleji:

http://www.webpagetest.org/result/110225_NT_25R0/

Až se toshi propracuje ke stahování objektů z více hostnames, bude jeho web ještě rychlejší.

Pak se mi bude moci omluvit za neopodstatněné osobní útoky.

25. 2. 2011 11:05:58

https://webtrh.cz/diskuse/zvlastni-lide-neumeji-nakonfigurovat-webserver/strana/7#reply610933

soudruh

(57 hodnocení)

26. 2. 2011 21:49:20

nemuzu si pomoct, stale polemika ohledne konfigurace a nacitani

- odrazovym mustkem je stale web webpagetest.org (ktery mj. propaguje i sam google ve webmasters tools)

ale proc tedy google podava sve vlastni vysledky minimalne 5x rychlejsi ?

konkretne: screen

---

a pro jistotu uvadim, ze jsem se zamyslel nad kompresi textu, ktera asi nicemu nebrani (dokonce na nekterych serverech uz bezela defaultne) - takze jsem ji na T3 enabloval

a vysledek ?

puvodni

http://www.webpagetest.org/result/110223_39_1MNY/

nyni

http://www.webpagetest.org/result/110226_82_2B9N/

zmenilo se pouze celkove "score" - casovy rozdil 5.4 a 5.3 sec je naprosta nula

score pred - 75/100

score po - 92/100

je to jen honeni bodu (pro nekoho mozna i neceho jineho :-) jako na seo-servisu - vysledek je pouze informativnim "kukatkem"

---

verim tedy spise vysledku google, ktery i petrx propaguje jako smerodatny

pokud mi hodnoti cely web dlouhodobe pod 1 sec., neresim tunning dle vyse zminovaneho

26. 2. 2011 21:49:20

https://webtrh.cz/diskuse/zvlastni-lide-neumeji-nakonfigurovat-webserver/strana/7#reply610932

Václav Dušek

(77 hodnocení)

26. 2. 2011 22:19:38

Ono je zapotřebí nejprve identifikovat úzké místo, které způsobuje největší zpomalení, a ne se honit za každou cenu za super hodnotami v nějakém testu. O rychlosti načítání webu (a obecně o všem v životě) rozhoduje vždy nejslabší článek řetězu.

Ta stránka http://www.webpagetest.org je dobrá pro rychlou orientaci a testování jednotlivých dílčích kroků, ale není všespasitelná.

Vůbec nezohledňuje zátěž serveru, výkon databáze a další faktory.

26. 2. 2011 22:19:38

https://webtrh.cz/diskuse/zvlastni-lide-neumeji-nakonfigurovat-webserver/strana/7#reply610931

petrx

(8 hodnocení)

27. 2. 2011 06:31:53

Napsal soudruh;630077
nemuzu si pomoct, stale polemika ohledne konfigurace a nacitani
- odrazovym mustkem je stale web webpagetest.org (ktery mj. propaguje i sam google ve webmasters tools)
ale proc tedy google podava sve vlastni vysledky minimalne 5x rychlejsi ?

1) Je možné, že významná část lidí používá webový prohlížeč, který se snaží pro jedno hostname otevřít více TCP spojení než dvě, načítání stránky by pak mohlo vypadat zhruba takto:

(zkus se podívat na podíly prohlížečů v Google Analytics)

Pokud prohlížeč otevře jen dvě spojení TCP na hostname, HTTP requesty odcházejí pomaleji:

Vznikne pak "husí pochod":

=> proto se vždy od vývojářů dožaduji, aby jednotlivé typy statických souborů byly servírovány z různých hostnames, přinutím tak webový prohlížeč

2) Lidé se na tvůj web opakovaně vracejí a/nebo během session navštíví více stránek najednou => HTTP requesty vedou ke kratším odpovědím webserveru (stavový kód 304 -- "Nezměněno")

Obecně však tyto žluté HTTP requesty jsou nesmyslné, zbytečně zatěžují server a bylo by lepší se jich zbavit explicititním nastavením doby cachování pro statické objekty

---------- Příspěvek doplněn 27.02.2011 v 06:49 ----------

Napsal vdusek;630085
Ono je zapotřebí nejprve identifikovat úzké místo, které způsobuje největší zpomalení, a ne se honit za každou cenu za super hodnotami v nějakém testu. O rychlosti načítání webu (a obecně o všem v životě) rozhoduje vždy nejslabší článek řetězu.
Ta stránka http://www.webpagetest.org je dobrá pro rychlou orientaci a testování jednotlivých dílčích kroků, ale není všespasitelná.
Vůbec nezohledňuje zátěž serveru, výkon databáze a další faktory.

To není úplně pravda, pomocí WebPageTest.org je možno nepřímo odhalit i pomalé generování HTML (=> nekvalitní dotazy do databáze, necachování fragmentů stránky uvnitř webserveru atd.). Pak je nutné naléhat na vývojáře, aby změřili dobu trvání jednotlivých dotazů / dobu generování jednotlivých fragmentů HTML a výkon pak spravili.

Například vývojáři webu www.parlamentnilisty.cz nezvládli generování homepage, HTML se sestavuje abnormálně dlouho:

http://www.webpagetest.org/result/110227_MF_2DFW/1/details/

27. 2. 2011 06:31:53

https://webtrh.cz/diskuse/zvlastni-lide-neumeji-nakonfigurovat-webserver/strana/7#reply610930

soudruh

(57 hodnocení)

27. 2. 2011 09:14:42

Napsal petrx;630168
Pokud prohlížeč otevře jen dvě spojení TCP na hostname, HTTP requesty odcházejí pomaleji:
=> proto se vždy od vývojářů dožaduji, aby jednotlivé typy statických souborů byly servírovány z různých hostnames, přinutím tak webový prohlížeč

o.k.

aby clovek nezkousel zbytecne - povazuje se v tomto smyslu za "jiny" hostname, pokud mas napr. neco.xx/images/soubor.jpg a images.neco.xx/soubor.jpg coz muzes jako cestu v kodu uvest i s http:// ? (uvazujme ze neco.xx je stejna domena)

nebo je potreba mit jinou ip a potazmo reverzni zaznam ?

coz lze take pridat na jednom serveru a servirovani "lokalne" bude z meho pohledu vzdy rychlejsi nez "od souseda"

27. 2. 2011 09:14:42

https://webtrh.cz/diskuse/zvlastni-lide-neumeji-nakonfigurovat-webserver/strana/7#reply610929

petrx

(8 hodnocení)

27. 2. 2011 12:44:05

Prohlížeč neřeší IP adresy a reverzní záznamy, řeší hostnames.

Takže není problém pro www.example.com mít alias css.example.com

A pro soubor typu http://www.example.com/styl.css zřídit alias http://css.example.com/styl.css

To samé pro JavaScripty, obrázky atd.

Samozřejmě stále platí, že CSS a JavaScript je vhodné sloučit do minimálního množství souborů, že je nutné zapnout HTTP kompresi atd., ale paralelizace stahování prostřednictvím paralelních spojení pomůže také.

Někdy nastane problém, že v redakčním systému není snadné přestěhovat např. generované náhledy obrázků na jiný hostname, resp. vývojářům se do toho nechce.

V tom případě je nutno přestěhovat na jiné hostnames alespoň soubory, které jsou pro všechny stránky společné (logo, pár ikonek, pozadí, JavaScripty, CSS)

Pokročilejším trikem je místo aliasů typu *.example.com pro web www.example.com vytvářet pro statický obsah aliasy *.example2.com -- použitím jiné 2nd level domény (example.com místo example.com) se vyhneme případným problémům s cookies a hlavně můžeme časem celé *.example2.com servírovat přes CloudFlare (=> obsah stále bydlí na www.example.com alias *.example2.com, ale záznamy v DNS vedou browsery k HTTP requestům na CloudFlare, kde je statický obsah zároveň cachován)

27. 2. 2011 12:44:05

https://webtrh.cz/diskuse/zvlastni-lide-neumeji-nakonfigurovat-webserver/strana/7#reply610928

wtpd

(19 hodnocení)

27. 2. 2011 23:45:35

Jsou to zajímavé informace, děkuji za ně. líbilo by se mi kdyby byl nějaký návod pro amatéry jak toto vše aplikovat. Nebo pokud znáte stránky kde jsou tyto návody uvedené.

27. 2. 2011 23:45:35

https://webtrh.cz/diskuse/zvlastni-lide-neumeji-nakonfigurovat-webserver/strana/7#reply610927

Martin

(62 hodnocení)

12. 3. 2011 01:46:33

Petrx to má očividně jako koníčka. Mě osobně by to teda nebavilo. Kvůli pár desetinkám, takový čachry na webu. Mě weby jedou dobře a kdyby ne, tak si připlatím pár stovek za lepší hosting :-)

12. 3. 2011 01:46:33

https://webtrh.cz/diskuse/zvlastni-lide-neumeji-nakonfigurovat-webserver/strana/7#reply610926

Václav Dušek

(77 hodnocení)

12. 3. 2011 06:31:59

Nejsou to desetinky - je to skutečně cesta ke zrychlení.

50% i víc na stávajícím hostingu je už zajímavých...

Byl jsem skeptický, ale něco na tom je

12. 3. 2011 06:31:59

https://webtrh.cz/diskuse/zvlastni-lide-neumeji-nakonfigurovat-webserver/strana/7#reply610925

wtpd

(19 hodnocení)

12. 3. 2011 20:05:35

Napsal vdusek;635242
Byl jsem skeptický, ale něco na tom je

Zapnul jsem na serveru GZIP kompresi textu a obrázku a pridal pokyn pro cachovani obrazku atd na strane prohlizece. Zvladne to i amater a rychlost nacitani webu se zdvojnasobila. Doporucuji

Bohuzel nedokazu posoudit zatez na server. Muze se dost zvysit podle me v nekterych pripadech.

Diky PetrX za navod.

12. 3. 2011 20:05:35

https://webtrh.cz/diskuse/zvlastni-lide-neumeji-nakonfigurovat-webserver/strana/7#reply610924

petrx

(8 hodnocení)

2. 4. 2011 00:11:32

Google uvedl testovací nástroj pro měření a vylepšování rychlosti webů:

http://techcrunch.com/2011/04/01/google-page-speed/

http://googlewebmastercentral.blogspot.com/2011/03/introducing-page-speed-online-with.html

https://groups.google.com/group/page-speed-discuss/

http://pagespeed.googlelabs.com/

http://pagespeed.googlelabs.com/#url=webtrh.cz&mobile=false

2. 4. 2011 00:11:32

https://webtrh.cz/diskuse/zvlastni-lide-neumeji-nakonfigurovat-webserver/strana/7#reply610923

Michal

5. 4. 2011 10:39:25

Ne nadarmo se rika, ze "Kazdy pribeh ma alespon dve verze". Mysleno podle toho, ktera strana pribeh vypravi.

V zasade se jedna o dva protichudne pozadavky typu:

1. Odlehcim datovemu spojeni (napr. tim, ze se snazim prenest mensi objem dat).

2. Odlehcim cilovemu serveru napr. tim. ze bude mene pocitat, spotrebuje mene RAM apod.

Tyto dva poazadavky ale jdou proti sobe, protoze (zatim) za bod 1 platim bodem 2 a za bod 2 platim bodem 1. Takze vysledkem je vzdy kompromis.

Co mne ale znepokojuje je fakt, ze ani jeden z diskutujicich se zatim nezabyval "trasou" tj. onim naprosto nezanedbatelnym faktem transportu dat po urcitem prostredi, ktere pod kontrolou tak z 99% nemam.

Docela rad bych tu videl nejakou tu tabulku, kolik strojoveho casu zabere komprese on-the-fly na jednom stroji pro 1,2,3,4,5-10-50-100 dynamickych webu apod. Kazda metoda ma totiz sve hranice.

Korektni a validni DNS zaznamy jsou bez diskuse (tedy, ano tady je to o adminovi, jeho peclivosti a jeho znalostech).

Mimochodem, takova poznamka pod carou, vrele doporucuji si do /etc/hosts (samozrejme na serveru) zapsat IP adresu a domenove jmeno vaseho vlastniho serveru (vsechna domenova jmena). Je celkem zbytecne ptat se "sam na sebe" ostatnich DNS serveru. V tomto pripade totiz dosti vyrazne usetrim jak na bodu 1, tak na bodu 2.

Michal

5. 4. 2011 10:39:25

https://webtrh.cz/diskuse/zvlastni-lide-neumeji-nakonfigurovat-webserver/strana/7#reply610922

petrx

(8 hodnocení)

9. 4. 2011 11:08:01

Napsal michal.linux;642936
Ne nadarmo se rika, ze "Kazdy pribeh ma alespon dve verze". Mysleno podle toho, ktera strana pribeh vypravi.
V zasade se jedna o dva protichudne pozadavky typu:
1. Odlehcim datovemu spojeni (napr. tim, ze se snazim prenest mensi objem dat).
2. Odlehcim cilovemu serveru napr. tim. ze bude mene pocitat, spotrebuje mene RAM apod.
Tyto dva poazadavky ale jdou proti sobe, protoze (zatim) za bod 1 platim bodem 2 a za bod 2 platim bodem 1. Takze vysledkem je vzdy kompromis.

Není tomu tak: Když zapnete korektně cachování na klientovi, ulehčíte i serveru

Když zapnete HTTP kompresi, budou muset server i klient více "počítat" v RAM, resp. v cache procesoru. Ale díky menšímu počtu paketů a díky kratší době spojení oba ušetří více na operacích během přenosu dat (čekání na odezvu protistrany apod.)

Je to podobné jako při šifrování dat: Šifrovací program často nejprve provede kompresi dat, což je jakoby práce navíc. Ale komprese je méně pracná než šifrování, takže se snížení objemu šifrovaných dat vyplatí.

Podobně při keep-alive je teoreticky otrava, že po načtení stránky včetně obrázků atd. zůstane TCP spojení ještě chvilku "viset". Ale zpravidla se více času ušetří eliminováním režie s otevíráním TCP spojení a s TCP slow-start, takže celkově se serveru odlehčí.

9. 4. 2011 11:08:01

https://webtrh.cz/diskuse/zvlastni-lide-neumeji-nakonfigurovat-webserver/strana/7#reply610921

petrx

(8 hodnocení)

29. 6. 2011 12:34:55

Objevily se další pěkné nástroje, které dokáží vypsat příčiny pomalosti podle priorit.

Příklad:

Webtrh.cz

http://173-203-64-171.static.cloud-ips.com/scan-files/free/dfa26baac9d2aedd5c7ad571c9e418db/report.html

http://gtmetrix.com/reports/webtrh.cz/i3BEL7fl

(pozor však na údaj o době načítání stránky -- gtmetrix.com měří pomocí Firefoxu na páteřní síti; pokud uživatel používá IE7 a/nebo ADSL, doba načítání bude delší)

http://pagespeed.googlelabs.com/#url=webtrh.cz

29. 6. 2011 12:34:55

https://webtrh.cz/diskuse/zvlastni-lide-neumeji-nakonfigurovat-webserver/strana/7#reply610920

nyccoss

(5 hodnocení)

30. 6. 2011 14:20:20

Napsal petrx;627781
Ty weby řeším pro SEO agenturu a mám podepsáno NDA :-(

Nicméně jeden z diskutujících mě privátně požádal, abych zkusil zrychlit jeho web => pokud by souhlasil, rád bych sem pak poslal výsledky (a zaprotokolovaný původní stav toho webu)

Take se pripojim do diskuze. Weby res pro koho chces. Pred par prispevky jsi tu vychvaloval nejaky eshop ze je perfektne vyresen. Zajimalo by me kdo z provozovatelu eshopu by se zlobil za umisteni linku na nejake forum. Tak sem posli link eshopu ktery jsi optimalizoval viz par prispevku vyse a ktery je perfektni a ma same "A".

Jsem tez nazoru, ze pokud mas pouze server ja jednu danou aplikaci/web, pak si pravdepodobne nastavis server presne tak jak potrebujes pro tu danou aplikaci. Pokud mas server s desitkami nebo stovkami webu / aplikaci, pak musi byt nastaveni preci optimalni pro vsechny aplikace/weby a musis najit zlatou stredni cestu a kompromisy mezi jednotlivymi castmi.... Universalni test je dobry pro porovnani jak moc to vyhovuje nebo ne. Ale stejne jako u seo-analyza nemusis dosahnout 100% aby jsi byl na prvnim miste.

Jeste je tady take jeden dulezity fakt k te rychlosti. Nemyslis ze treba delay u first-byte muze byt zpusoben tim, ze testujes ceske weby ze serveru ktery bude patrne umisten mimo CR (nezjistoval jsem). Ne vsechny trasy jsou stejne rychle a par desitek milisekund je dost pravdepodobne zpusobeno cestou mezi web serverem a timto tvym universalnim testovacim serverem.

Muzu tedy poprosit URL toho eshopu ktery jsi tu vyzdvihoval pouze jako example.com, example2.com??

30. 6. 2011 14:20:20

https://webtrh.cz/diskuse/zvlastni-lide-neumeji-nakonfigurovat-webserver/strana/7#reply610919