Rychlost / testování rychlosti
- maikoo
- Člen | 21
Zdravím,
s nette začínám a chci ho zkusit použít u jednoho projektu zajímalo by
mě jaká má úskalí co se týče výkonu…
Jde mi hlavně o to aby při větší zátěži některé „fíčury“
zbytečně nezpomalovali chod celé aplikace a přitom bych tu či onu část
kodu mohl buď přepsat nebo ji nepoužívat a zvolit třeba „horší
řeší“ jen kvůli lepšímu výkonu.
Zatím jsem našel na foru pouze problém s generováním odkazů .. https://forum.nette.org/…ovani-odkazu
Tak pokud máte někdo nějaké zkušenosti děkuji za jakékoliv rady
Pak by mě zajímalo co používáte pro test rychlostí? … dá se nějakým programem simulovat zátěž www, udělat takovou simulaci např 5000 návštěvníků kteří provedou nějakou akci? .. a popřípadě pomocí nějakých výsledků dojít k nějakým závěrům
diky moc za rady
- ic
- Člen | 430
Čas se dá celkem sledovat pomocí Debug::timer() viz. https://tracy.nette.org/cs/#…
. Jak nasimulovat více návštěvníků co by prováděli různé akce to
nevím… mohl by na to pomoct CRON nebo opakování nějaké akce cyklem, ale
živý provoz to asi nenahradí.
Důležité je využívat cashování jak na serveru tak u klienta.
5000 návštěvníků v jeden čas je fakt hodně, to už je taky otázka hostingu, z levnějších (to by neustáli) už by asi hned psali maily ať si připlatíš. To leda urazit WikiLeaks a počkat na útok (jestli je to ještě baví) XD
- na1k
- Člen | 288
Na žádném supervelkém webu Nette nasazeno nemám, ale myslím že optimalizace je něco, na co se v Nette hodně hledí. Jak vnitřně, tak pro programátora, který má k dispozici celkem rozsáhlou podporu kešování. Proto si myslím že s rychlostí by neměl být problém.
Orientačně může pro měření posloužit debugbar, který ukazuje dobu generování stránky a do kódu si můžeš vložit jednoduše stopky, které ti změří jak dlouho trvají jednotlivé části, které pak můžeš dál optimalizovat.
Co se týče testování zátěže, asi by mohlo jít (minimálně pod linuxem) napsat nějaký skriptík, co by chrlil dotazy (například pomocí telnetu) a pak bys nějak měřil vytížení. Nevím jestli to umí sám apache, ale v nejhořším by se dalo z toho, čím web odpoví skriptu vyparsovat jak dlouho generování trvalo (debugbar). Je to ale jen myšlenka a simulace by to byla jen velice přibližná a od skutečného serveru se může dost lišit.
- Acci
- Člen | 83
do kódu si můžeš vložit jednoduše stopky, které ti změří jak dlouho trvají jednotlivé části, které pak můžeš dál optimalizovat.
To je jednoznačně práce pro profiler – Xdebug na Windows nebo XHProf na Linuxu.
Zátěž se dá testovat pod linuxem aplikací ab, u které lze nastavit konkurence požadavků a ne výstupu dostaneš celkem podrobnou statistiku (počet dotazů za sekundu, délka jednoho požadavku, střední hodnotu a rozptyl).
- bojovyletoun
- Člen | 667
na prohlížení výstupu z z xdebugu se hodí wincachegrind
nějaké časy: Stránka s kontigenční tabulkou 20×40 (tedy asi 800 odkazů):
- Core 2 double, 2300MHz, Apache2module, PHP5.3.5, nette 2 2011–1-?
- s odkazy:720ms =
<a class="ajax" n:tag-if="$allowed" href="{link "tgl!", $u->id,$a->id }">{$status?'ANO':'NE'}</a> - s odkazem generovaným jen jednou a pak jen str_replace a dosazení
parametrů odkazu: 490 ms
=
<a class="ajax" n:tag-if="$allowed" href="{!$cached|replace:["XX","YY"],[$u->id,$a->id] }">{$status?'ANO':'NE'}</a>, tomu předchází{capture $cached}{link...}{/capture} - bez odkazů 490 ms = <a class=„ajax“ n:tag-if=„$allowed“ href=„empty“>{$status?‚ANO‘:‚NE‘}</a>
- pro srovnání: 800 Appformů 4000ms
Ale co mě zaráží je toto:
chtěl jsem si "odkaz: nějak cachovat, takto: 1500ms !!
href="{block|replace:['PARAMA','PARAMB'],[$u->id,$a->id]}{cache}{link "tgl!", PARAMA, PARAMB }{/cache}{/block}
- Filip Procházka
- Moderator | 4668
bojovyletoun:
Příjde mi to vcelku logické, kešování ti taky něco sežere a určitě
se tam děje na pozadí nějaká prasárna :-/. Větší smysl by dávalo
udělat si rozšíření Nette\Application\Link, vlastní metodu
$presenter->cachedLink s taky asi i přepsat macro. Potom
nebudeš muset řešit takové hacky v šabloně :)
Ostatně, asi to doma udělám večer, mohlo by se to hodit, pokud to uděláš dřív tak to hoď na forum :)
Editoval HosipLan (24. 1. 2011 8:13)
- ic
- Člen | 430
Dneska vyšel článek o nějaké konkurenci pro xDebug : http://zdrojak.root.cz/…moci-xhprof/
- Acci
- Člen | 83
Pro cachování odkazů je nejlepší přepsat funkci link
v presenteru a použít tak přímo kód
od Davida.
bojovyletoun: Makro {cache} se ukládá do souboru, takže při načítání stránky se musí načít obrovské množství souborů a u nich ještě zkontrolovat hlavičky, takže se hodí spíš pro větší bloky stránky než jednotlivé odkazy.
ic: Líbí? :-)
Editoval Acci (24. 1. 2011 11:51)
- maikoo
- Člen | 21
skrivy napsal(a):
Pred nasazenim nette bezel jeden vetsi projekt na 2 serverech. Po nasazeni bezi na 8mi :) takze asi tak …
jak je to možné ? … našli jste kde je problém? nebo jste to předpokládali ? :D
… zajímalo by mě kolik akcí je prováděno ve špičce v jeden okamžik? (..že je potřeba výkon 8 serverů)
Editoval maikoo (27. 1. 2011 13:21)
- Jan Tvrdík
- Nette guru | 2595
Jestli jste ze dvou serverů přešli na 8, tak to máte velmi pravděpodobně blbě napsané.
- bojovyletoun
- Člen | 667
tak jsem zkusil i kcachegrind pro windows a hlavní zádrhlel je obvykle v dibi.:fetch(all,assoc,–--), s tím se ale nic neudělá a pak v následném vypisování těch samých velkých dat… Jde o tabulku asi 40×16.
Nicméně mám pár rad:dám příklad
- optimalizace sql na prvním místě, například doma to běží ok (20ms) ale na hostingu 500ms- výše uvedený select tabulky 40×20 (ve skutečnosti 8 privázaných tabulek). Tento nepoměr je jen mezi sqlite. Po optimalizaci: doma 2ms, hosting 6ms. Takovéhle selecty byly 4 – generování stránky 4s. Po optimalizai 800ms
- Vypnout dibi profiler: 800ms->600ms
- inteligentní cachování odkazů(800 odkazů) – mínus 100ms
- použití minified NEtte (doma z 400 na 280ms)
- minified dibi (doma z 280->240) (na servru bylo minified defaultně)
- zvážit eaccelerator
- apache modul místo cgi
Takže změna: server: 4000ms->400ms, doma 700ms->250ms
- skrivy
- Člen | 51
Jan Tvrdík napsal(a):
Jestli jste ze dvou serverů přešli na 8, tak to máte velmi pravděpodobně blbě napsané.
Ono to předtím bylo napsané úplně bez řádu – čili bastl (míchaný html s phpkem a podobně, nepoužívalo se tam ani oop ani nic jiného), čili se prováděl jenom kód, který byl nezbytně nutný k běhu aplikace a nic dalšího.
Editoval skrivy (28. 1. 2011 12:54)
- David Grudl
- Nette Core | 8142
Aby se s tím dalo něco dělat, je třeba pomocí profileru odhalit slabé místo – to může být jak v aplikaci samotné, tak klidně i v Nette, proč ne. Ale bez analýzy to nelze opravit.
- Panda
- Člen | 569
bojovyletoun napsal(a):
- apache modul místo cgi
Paradoxně to nemusí být nejlepší řešení. Na serveru jsme benchmarkovali Apache + mod_php vs. nginx + php-fpm a co se týče počtu požadavků za sekundu, tak to bylo srovnatelné, php-fpm jelo možná o kousek lépe. Razantní rozdíl byl vidět ve chvíli, kdy jsme se serveru pokusili naložit víc, než zvládá (tzn. víc, než měl apache/FPM childů) – u drobných skriptů, které nepracovaly s databází, Apache klesnul z cca 2800 na 400 req/s, FPM z 2900 na asi 2500 req/s. Důležitá je ale ta kombinace nginx + php-fpm, Apache by to tolik nezvládal, protože nginx i při stovkách současných spojení zabere v RAMce jen pár (desítek) MB.
- bojovyletoun
- Člen | 667
Já zatím píšu aplikace, kde je maximálně 1 request za 400 sekund. :)
Ale proč vlastně reaguji: když jsem přešel z cgi na modul, tak rozdílů v generování samotné stránky (měřeno dle Debugpanelu třeba) jsem si nevšiml. Jenži při CGI se při kliknutí na odkaz nebo otevření stránky první 3 sekundy nedělo nic"((se asi spouštělo php.exe)) a pak se stránka „rychle načetla“. Rád bych věděl čím to. Měl jsem Abbyss Web Server X1. Kromě toho v apache funguje mod_rewrite :)
Editoval bojovyletoun (10. 2. 2011 16:51)