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

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

Původně odeslal michal.linux

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

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-i...db/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

Původně odeslal petrx

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

25.02.2011 10:08:

Původně odeslal petrx

Mám nyní souhlas od klienta z Webtrhu (ozval se mi na základě tohoto diskusního vlákna) se zveřeněním údajů o rychlosti webu, jehož rychlost se mi podařilo zvýšit.

Jedná se o web www.silver.ag.


Původní rychlostní parametry webu:

http://www.webpagetest.org/result/110219_YX_1065/
První zobrazení: 12.646 sekund
Opakované zobrazení: 11.444 sekund


Po opravě nastavení HTTP komprese, cachování a persistentních spojení (keep-alive):

http://www.webpagetest.org/result/110225_WJ_21HG/
První zobrazení: 6.326 s ekund
Opakované zobrazení: 2.311 sekund


První načtení stránky www.silver.ag (s prázdnou cache v browseru) se tedy zrychlilo dvojnásobně.

Opakované zobrazení se zrychlilo pětinásobně.


Vývojáři a administrátoři webu se změnám bránili, nakonec se však většinu změn podařilo provést.

Chybí ještě jedna důležitá změna, přesun statického obsahu na separátní hostnames (css.silver.ag, js.silver.ag, gif.silver.ag...), k té by mělo dojít později => očekávám další zrychlení webu

---------- Příspěvek doplněn 30.06.2011 v 20:20 ----------

Původně odeslal nyccoss

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.

Některé parametry jsou platné obecně (keep-alive, cachování, komprese HTML+CSS+JS, konsolidace CSS, JS a obrázků)

---------- Příspěvek doplněn 30.06.2011 v 20:22 ----------

Původně odeslal nyccoss

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.

Nejraději měřím z Frankfurtu, který je z hlediska topologie Internetu blízko (krátká geografická vzdálenost + srovnatelný počet hopů, jako kdybych se připojoval z českých sítí)

Pochvala provozovateli WebTrhu za odstranění nejhorších problémů, které brzdily načítání jeho stránek:
http://webtrh.cz/145124-novy-server

Vdaka za toto vlanko a pouzivatelovi petrx za vela nervov pri vysvetlovani neveriacim :). Taktiez sa nahanam za kazdou miliseknudou a toto vlakno mi do buducna urcite pomoze.

Spíše než toto vlákno ti pomůže:

- www.WebPageTest.org

- http://zoompf.com/free

- statistiky crawlování (a chyb při něm) v Google Webmaster Tools

- statistiky doby načítání z Google Toolbaru v Google Webmaster Tools

- asertivita v jednání s adminy / vývojáři / dodavateli

Zdravím všechny,

Věnoval jsem čtením této ne zrovna krátké diskuze dost času, musím říci, že to nebyl úplně ztracený čas. Nicméně si nedovolím neutrousit jednu poznámku, Teorie je velmi odlišná od praxe. Pokud poskytujete na svém jednom stroji aplikace pro více zákazníků a každá z těchto aplikací má jiné nároky tak se nedá aplikovat některá z nabízených(někdy až nevybíravě propagovaných) řešení. Nemůžete každému gzipovat JS či CSS jenom proto, že Vám to přijde to nejrozumnější řešení - Nehledě na to, že tohle řešení má význam až u x unikátů denně, jinak bych hledal problém na straně Server-Side skriptů a ne ve velikosti JS či CSS dokumentů.

Jinak palec nahoru odpovědím toshiho a smsaffiliate - tito kluci evidentně vědí jak to chodí v praxi!

Jakub Strzadala

Mozte sem niekto napisat ako by malo vyzerat rewrite pravidlo pre htaccess tak aby odkazy smerujuce na obrazky isli cez subdomenu img ?

Původně odeslal New thinking media

Pokud poskytujete na svém jednom stroji aplikace pro více zákazníků a každá z těchto aplikací má jiné nároky tak se nedá aplikovat některá z nabízených(někdy až nevybíravě propagovaných) řešení. Nemůžete každému gzipovat JS či CSS jenom proto, že Vám to přijde to nejrozumnější řešení - Nehledě na to, že tohle řešení má význam až u x unikátů denně, jinak bych hledal problém na straně Server-Side skriptů a ne ve velikosti JS či CSS dokumentů.

Problémy s výkonem skriptů jsou separátní kapitola a ovlivňují generování + načítání kódu HTML

CSS a JS bývají statické soubory a pokud jsou servírovány neefektivně, brzdí zobrazení stránky bez ohledu na rychlost / pomalost generování HTML

A když jsme u toho, CSS a JS můžeme s výhodou servírova z jiného hostname.

Děkuji za načatí výborného tématu. Jsem rád, že se o to někdo také více zajímá. Nějakou dobu to sleduji jak si můžete zkontrolovat můj blog, dost experimentuji a plánuji sepsat jednoduché návody pro všechny, pro co možná nejlepší nastavení webu pro rychlé načítání. Kdo má zájem dnes jsem napsal svůj první návod o tom jak aktivovat gzip kompresi u CSS a JS. Budu moc rád, když se k němu v komentářích u článku vyjádříte. Postupem času napíšu další návody a doufám, že padnou na úrodnou půdu :).