MaxExecutionTime u profileru
- Jakub Šulák
- Člen | 222
Nešlo by u profileru přidat možnost nastavit nějaký maximální čas běhu skriptu, přičemž by po překročení tohoto času došlo k vyhození vyjímky na úrovni E_NOTICE?
Jedná se mi o to, že testujeme kód na lokálním serveru, kde je logicky vše rychlejší. Na serveru se pak setkáváme někdy s tím, že co bylo rychlé u nás, na serveru je neskutečně pomalé – pustit tam ale profiler logicky nelze. Takže se to musí ukládat do log souboru, nebo posílat mailem – obojí umí již současný Nette\Debug. Takže změna profileru by byla minimální – lepší než přidávat celou vlastní třídu, která by se o to starala.
Ale je to jen návrh…
- PetrP
- Člen | 587
Jakub Šulák napsal(a):
pustit tam ale profiler logicky nelze.
Proč by nešel pustit profiler? Můžu si přece aplikaci otestovat například na jiné subdoméně. Myslím že je to dokonce lepší než to rovnou pustit do ostrého provozu a modlit se aby tam nebyl nějakej rozdíl oproti serveru doma.
Nešlo by u profileru přidat možnost nastavit nějaký maximální čas běhu skriptu
A proč to neřešit sám pár řádkama kódu?
// začátek scriptu (mohl bych asi použít i defaultní měřič)
Debug::timer('MaxExecutionTime');
// někde na konci
if (Debug::timer('MaxExecutionTime') > MAX_EXECUTION_TIME)
throw new MaxExecutionTimeException;
nebo // protože jsem nepochopil zda má být vyhozena vyjímka nebo E_USER_NOTICE
trigger_error("MaxExecutionTime", E_USER_NOTICE);- Jakub Šulák
- Člen | 222
ad 1)
Na subdoméně testuješ stále jen „uměle“ – pokud máš ve špičce
během minuty vygenerováno cca 1000 stránek, začíná se skript (z hlediska
výkonu) chovat někdy jinak (především například při přístupu k DB,
nebo filesystému). Dále se tak dá právě zjistit špičky (a například
vyřadit v té době nějaké dávky – CRON).
ad 2) Jelikož je to právě pár řádků, napadlo mě, že by to šlo dát přímo do Nette – něco podobného totiž již nyní v naší aplikaci běží.
- o5
- Člen | 416
Z grafu zde to tedy u Nette (je to ale staré měření) moc nevypadá, ale jinde je použítí eAccelerator docela přínosem. Ale nezkoušel jsem to.
- Jakub Šulák
- Člen | 222
to phx: Záleží na aplikaci – někde se projeví to, že skript běží
v n instancích.
Ad zrychlení aplikace – záleží co ti tu aplikaci zpomaluje –
databáze, algoritmus, příliš velké nepotřebné objekty… Jinak mám
aplikaci, která má cca 150 objektů a kolem 5000 řádků kódu (oboje
odhad) a nyní jsem například model (cca 70 objektů) sjednotil do jednoho
souboru (compressed verze) – nárůst výkonu o cca 30%. Stejně tak je
velký rozdíl, zda používám compressed verzi Nette a dibi (případně
dalších knihoven).
- PetrP
- Člen | 587
Jakub Šulák napsal(a):
ad 1)
Na subdoméně testuješ stále jen „uměle“ – pokud máš ve špičce během minuty vygenerováno cca 1000 stránek, začíná se skript (z hlediska výkonu) chovat někdy jinak (především například při přístupu k DB, nebo filesystému). Dále se tak dá právě zjistit špičky (a například vyřadit v té době nějaké dávky – CRON).
Tak můžeš zátěž generovat. U více navštěvovaného webu zátěžovej test bude asi nutností. A skoušet to na skutečných lidech vidím jako nešťastné ;]
ad 2) Jelikož je to právě pár řádků, napadlo mě, že by to šlo dát přímo do Nette – něco podobného totiž již nyní v naší aplikaci běží.
Otázka je jestli by z toho měl někdo užitek. A hlavně by to nemohlo bejt součástí profileru, protože ten se na produkčním serveru nezapíná. Takže by se pro to musela udělat další udělátko, které by se muselo zapínat a taky nějak nastavovat ten čas při kterým to ‚zařve‘. To zapnutí tohohle udělátka vyjde na stejné množství kódu jako když to rovnou někam zapíšu. A taky funkce register_shutdown_function (předpokládám že přes ní je profiler dělanej) nemůže obsahovat exception, takže by se to muselo dávat jinam. Ale kam?
- Jakub Šulák
- Člen | 222
ok, nechám to na aplikaci, aby to hlásila…
PS: S tím zátěžovým testem je to fajn základ, ale neodhalíš vše –
v reálu je to vždy trochu jinak (především asi tím, že lidé
používají aplikaci jinak než vývojáři).
- David Grudl
- Nette Core | 8142
Profiler by měl mít XDEBUG, je také součástí IDE Nusphere PHPEd.
Jinak request trvající 1 s mi připadá hodně moc. To by chtělo zjistit, co to brzdí.
- edke
- Člen | 198
phx wrote:
Nevite nekdo o necem free? (Eclipse PDT to nema a nebo jsem to nenasel:( )
Ako pisal David, profiler obsahuje xdebug. Len neviem ci na tom servri mas pristup ku konfiguracii webservra.
Potom v zavislosti od linux distribucie, resp. windows konfiguracie musis zmenit xdebug.ini pre php5. Napriklad na ubuntu to je vo /etc/php5/conf.d:
xdebug.profiler_enable=1
xdebug.profiler_output_dir=/tmp/xdebug-profiler
xdebug.profiler_output_name=grind.%s.outCi naozaj si profiler zapol je dobre skontrolovat cez phpinfo(). Ked uz profiler bezi, kazdy request vygeneruje do output_dir grind subor, ktory potom analyzujes v programoch ako napriklad KCacheGrind pod linuxom, alebo WinCacheGrind pod win. Viac info aj s linkami ku programom najdes tu.
- edke
- Člen | 198
phx wrote:
Supr… tak na to koukam a profiler mi tvrdi 490ms ale muj merenej cas ukazuje 4.6879s.
Napada mne ze by to mohlo byt zdrzovano necim co profiler nezapocitava. (cekani na systemove fce, parsovani PHP zdrojaku)
Nejake napady?
Hm, zvlastne a ako si dostal ten tvoj cas ? Meral si to cez profiler ? Potom povedal by som ze ti neostava, ako to pracne pomerat cez Debug::timer(), postupne, cez jednotlive useky aplikacie.
- PetrP
- Člen | 587
pmg napsal(a):
Možná to napojit na
$application->onStartupa$application->onShutdown? Ale to je detail.
$application->onStartup se volá až v
$application->run() a i tam se před tím např nastavujou
hlavičky, to nepočítám že v bootstrapu můžu mít bůhvíjak náročnou
činnost. Takže je na měření doby běhu skriptu nevhodné.
$application->onShutdown by na toto asi bylo
použitelné.
Ale to je taky jen detail ;]