skokové zvýšení návštěvnosti přes noc, nemáte tipy co dělat?

• statická data (js, css, img, …) dej na jiný server a použij tam např. lighttpd, hlavně ne Apache
• pokuď tam máš hodně požadavků na js a css, zkus spojit související js do jednoho (a stejně css)
• malé obrázky taky můžeš spojit do jednoho (css sprites)
• o hodně můžeš snížit počet requestů tak, že si při každém deployi vygeneruješ nějaký hash a ten přidáváš do URL všech statických dat (např.: http://example.com/img.jpg?… ) a pak můžeš odesílat hlavičku, že stačí soubor kontrolovat třeba 1× za den. A při dalším deployi se změní hash, prohlížeč to bere za nový soubor a zase si ho vyžádá.
• případně dej statická data na nějaké CDN a máš to pořešené (ale zase za to zaplatíš)

1. css/js sprity jak říkám používám webloader, nicméně ten prostě když spojuje 20 souborů tak udělá 20× filemtime a to je problém
2. image sprity no o nich vím, ale doporučujete udělat sprite na celý náhled? protože ono těch buttonů a ikonek je dohromady tak 5–10 víc prostě ne, ale jo je mi jasné že je to jedna z věcí
3. CDN, jiný server hmmm, jen si říkám jestli je to reálné pořizovat další hosting? nebo další server?
4. varnish mi nic neříká zkusím prohledat

tohle taky zajímavé
o hodně můžeš snížit počet requestů tak, že si při každém deployi vygeneruješ nějaký hash a ten přidáváš do URL všech statických dat (např.: http://example.com/img.jpg… ) a pak můžeš odesílat hlavičku, že stačí soubor kontrolovat třeba 1× za den. A při dalším deployi se změní hash, prohlížeč to bere za nový soubor a zase si ho vyžádá.

to musím promyslet

Editoval mcmatak (8. 2. 2012 14:35)

1. To nejde cache je pravé založena na těch 19 filemtime, nevím jak to obejít
2. 10 ikonek na cely projekt jsou třeba dva Buttony na page tady toho moc nenazenu, mě spis zajímá jestli existuje něco aby prohlížeč si vůbec o cachnute obrázky neříkal?

Jo to beru to zni dobře ale kolik me to bude stát? Jak to zařídit další server není žádná sranda

nginx + PHP FastCGI Process Manager, tím získáš poměrně snadno nějaký výkon i bez dalšího serveru (zvlášť co se týče toho statického obsahu, ale i to PHPčko se bude pak mnohem lépe vypořádá se zátěží).

Jinak pro obrázky, JS a CSS přidat expires, obsah předgzipovat, nasadit APC (pokud ještě není), upravit ten WebLoader…

A právě nginx nic jako „apačský .htaccess“ nezná a proto může mít takový výkon. ;-)

.htaccess je k ničemu. Je to soubor, který se modifikuje jen jednou za několik měsíců/let a pak se z něj jen milionkrát za den zbytečně čte. A přitom to jde všechno pohodlně nastavit v configuráku vhostu. Pokud někomu na projektu vadí 19× filemtime, tak první, čeho by se měl zbavit, je právě .htaccess.

Mimochodem: zkus si poslat 500 současných PHP požadavků na Apache + mod_php a pak nginx + PHP FPM. Druhá konfigurace se s tím vypořádá mnohem lépe.

mcmatak napsal(a):

Nox: Nj ale já nevím jak to přepsat, název souboru je přece unikátní a závisí na aktualni verzi všech > 20 souboru a proto je tvořen nejakym hash z jejich nazvu jak jinak to uděláš?

Dáš to tak, aby metoda příjmala identifikátor, který pak použije pro vytvoření jména … podobně jako u cache->save používáš nějaký key místo aby to byl hash obsahu

mcmatak napsal(a):

Nox: jeden z nás to nedomyslel do konce, jak určit ten identifikátor? Na zaklade čeho? Protože obvykle to bude nejvyšší filemtime nebo názvy ale jak ten identifikátor vytvořit?

Co to je za web, že to tak strašně řešíš? Přeci stačí ty soubory přegenerovat, pouze když tam něco změníš … nebo ty css a js se ti tam mění nějak za chodu samy?
Při deploy nové/upravené verze nevidím zas tak velký problém smazat nějaký výsledný vygenerovaný soubor, aby se přegeneroval znovu sám.
Spíše bych se zaměřil na ten statický obsah, expire, cache apod.

mcmatak napsal(a):

Nox: Nj ale já nevím jak to přepsat, název souboru je přece unikátní a závisí na aktualni verzi všech 20 souboru a proto je tvořen nejakym hash z jejich nazvu jak jinak to uděláš?

Pokud mám hodně navštěvovaný projekt měl by statický obsah (JS, CSS, obrázky) servírovat přímo HTTP server (právě z důvodů snížení zátěže). Proto bych se vykašlal na celej webloader (nebo jak se to jmenuje). A řešil vytvoření jednoho minifikovaného CSS / JS souboru už při deploymentu.

… ale jak vyřešit aby se na ne browser vůbec neptal?tak jako tak to bude req ne?

Pošleš patřičné hlavičky. Neco o tom je v tom videu o Varnish cache nebo http://symfony.com/…aris2011/574 nebo tady http://webexpo.cz/…ie-kesovani/

Nginx bude pro mého správce asi moc divoká voda

Tohle je ale jedna z věcí, která dokáže serveru doopravdy hodně ulehčit.

Už se o tom tady mluvilo: expires header a/nebo hash https://forum.nette.org/…ipy-co-delat#…

mcmatak napsal(a):

Panda: gzip děla server automaticky, apc mám,

To určitě dělá, ale při každém požadavku a pak výsledek zapomene. :-) To předgzipování je kvůli tomu, aby se nemuselo při každém požadavku znovu komprimovat a aby se mohl načítat menší soubor.

Jinak mě ještě napadla jedna věc, jak poměrně levně zvýšit hodně výkon – RAM disk. Pokud bys tam dal ten obsah, ke kterému se často přistupuje (JS/CSS + třeba PHP, ale s APC to asi nemá moc význam), tak by to mohlo hodně ulehčit disku a snížit přístupové doby.

V první řadě bych ale analyzoval, co nejvíc zpomaluje a nasadil ten nginx + PHP FPM. Na konfiguraci není nijak složitý a ulehčí opravdu hodně.

ic napsal(a):

Sice to přímo nesouvisí s nette, ale hodně pomůže zmenšit počet obrázků…

To už tady padlo, jedná se o výše zmíněné CSS sprites

CSS3 je taky cesta, ale bohužel ještě ten support ze strany prohlížečů není úplně tak, jak bychom si to představovali…