Dlouhe nacitani po upgradu Nette

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
lukyrys
Člen | 36
+
0
-

Zdravim, nesetkal se nekdo s rapidnim narustem execution time po upgradu nette?
Upgradoval jsem konkretne z 2.0.7 na 2.3.5. Konfigurace je totozna, cache jede pres redis a podle vseho byla funkcni jako pred upgradem. Ve slozce cache byl pouze robotloader latte a konfigurator slozky.
Doby nacitani MySQL zustali stejne jen zpracovani php rapidne narostlo z puvodnich 100ms na 1500–2000ms.
Nenapada me vubec na co se zamerit..

Azathoth
Člen | 495
+
0
-

zkus tam pustit profiling, to by ti mělo něco do začátku říct

potapnik
Člen | 127
+
0
-

A to hlásí Tracy bar? Těch 1500–2000? Jestli ne, tak je možné, že tam někde nefunguje DNS lookup (ta prodleva by odpovídala), zkus se kouknout, jestli tam někde v konfiguraci není localhost a nahraď ho 127.0.0.1. Něco se každopádně změnit muselo :-) Jinak upgrade z 2.0 na 2.3 by chtěl určitě updatnout spoustu interních věcí, aby to šlapalo pořádně s novými features :-)

lukyrys
Člen | 36
+
0
-

Tak odchytal jsem par nepresnosti a konvenci ktere se zmenili verzemi, jinak ano tracy ukazuje ten cas.. zkusim profiler problem je ze to musim oddebugovat na ostry. na localu tohle nema smysl resit apache nechodi tak jak to ma chodit na serveru rychlostne

lukyrys
Člen | 36
+
0
-

Profiler tvrdi ze se jedna o cteni z cache pri setTable() nad NDB..
viz http://502.cz/…13350213.png
Mam pocit ze to bude zpusobeny tim ze se do redisu saha pro moc dat vzhledem k tomu ze databaze aplikace ma pomerne dost tabulek. Neco kolem 2tis.
Lze nejak rict NDB aby structure (ktery je pro me tim upgradem novy) ukladat do souboru?

Tak dela to funkce Kdyby\Redis\RedisStorage::getUnserializedValue takze to vypada na obri mnozstvi dat coz potrvrzuje moji teorii

Editoval lukyrys (2. 10. 2015 23:43)

enumag
Člen | 2118
+
+2
-

Jen ze zvědavosti, jakým nástrojem děláš ten profiling? Vypadá to podezřele podobně jako Tracy, ale nevím o tom že by Tracy měla profiler.

Editoval enumag (3. 10. 2015 0:00)

lukyrys
Člen | 36
+
0
-

enumag napsal(a):

Jen ze zvědavosti, jakým nástrojem děláš ten profiling? Vypadá to podezřele podobně jako Tracy, ale nevím o tom že by Tracy měla profiler.

Je to tohle – https://github.com/…ugTracePanel jako extension panel do tracy

lukyrys
Člen | 36
+
0
-

No tak je to tou strukturou. Cache soubor ma 22MB a unserialize() nad tim trva prave takhle dlouho..
95% tabulek ma totoznou sturkturu takze by sla nadefinovat staticky.. ale nemuzu vyzkoumat postup jak prekryt Nette\Database\Structure necim vlastnim nebo vymyslet neco jinyho.

EDIT: Ok tak lze to prekryt pres config v services pridat database.default.structure: My\Database\Structure(@database.default.connection,@cacheStorage)
Tak jde se badat :) Kdyby mel nekdo nejake pripominky/napady tak budu za ne rad

EDIT2: Tak vyreseno, dopsal jsem si vlastni strukturu pro tabulky ktere jsou totozne aby se necpali do cache, cas zpracovani teto manualni upravy mensi nez automaticky, ale neumim si predstavit jak to resit v pripade ruznych tabulek ve velke databazi..

Editoval lukyrys (4. 10. 2015 4:33)

enumag
Člen | 2118
+
0
-

@lukyrys To extension pro Tracy je nekompatibilní s Nette 2.3, které ty ale používáš. Máš někde kompatibilní fork? :-)

lukyrys
Člen | 36
+
0
-

enumag napsal(a):

@lukyrys To extension pro Tracy je nekompatibilní s Nette 2.3, které ty ale používáš. Máš někde kompatibilní fork? :-)

Nemam, me funguje jen jsem musel upravit XDebugTrace.php (asi vlivem jiny verze php) a pouzivam ho v podobe 2c) – https://github.com/…ter/HOWTO.md a pak start() / stop()

} elseif (!preg_match(‚/^File format: 2/‘, (string) fgets($fd, self::$traceLineLength))) {

na

} elseif (!preg_match(‚/^File format: 4/‘, (string) fgets($fd, self::$traceLineLength))) {