Pomalé načítání nette až 3 000ms
- B30wu1f
- Člen | 7
Dobrý den,
Mám php 5.3.6 a nette verze 2.0-beta pro PHP 5.3 a mám neskutečné
problémy s načítáním stránky. Podle screencastu se snažím vyrobit menu
a když kliknu na nějakou položku, tak to načítá dost dlouho (3338.2ms) a
opravdu nevím čím to může být.
Používám VertrigoServ 2.24 a mám upravený config na import větších SQL
souborů do phpmyadmin.
Děkuji za pomoc.
- Jan Endel
- Člen | 1016
Pokud se ti pomalu načítá menu, zkus ho cachovat. Dokumentace je popsána pěkně.
- Filip Procházka
- Moderator | 4668
To není konfigurace PHP, ale kontrola závislostí.
Zkontroluj si, jestli máš nastavené, aby se ti nerebuildoval cache
RobotLoader a taky jestli nemáš třeba Debugger::$maxDepth
moc velké.
- B30wu1f
- Člen | 7
HosipLan napsal(a):
To není konfigurace PHP, ale kontrola závislostí.
Zkontroluj si, jestli máš nastavené, aby se ti nerebuildoval cache RobotLoader a taky jestli nemáš třeba
Debugger::$maxDepth
moc velké.
Nevím kde se nachází debugger::$maxDepth :) dnes jsem s frameworkem začal ;)
- Ot@s
- Backer | 476
B30wu1f napsal(a):
Intel Core 2 Duo 1,6GHZ
2GB ram DDR2
HDD 150GB nevím značku
Jestli je to aplikace hostovaná pod widlemi (navíc s databází tamtéž), to celé na dnes již „obstarožním“ 150GB disku, tak je to +/- „v pořádku“. Koukni na debugbar, resp. na databázový profiler (jestli používáš), jaké odezvy mají SQL dotazy? Případně vyzkoušej nějaký „konkurenční“ PHP framework/CMS. Myslím, že odezvy budou podobné.
- 22
- Člen | 1478
3000 ms mi teda přijde opravdu moc. Já na mým starým serveru P4 1,8 Ghz (Win2003/Apache), přes lokální síti běžnou rychlost sandboxu 280–330 ms, a to určitě nebude rychlejší než DualCore z lokálního disku.
Čekat 3 sekundy ne dev mašině na vykreslení webu, to je lepší nedělat nic, protože bych přišel o nervy po 10. refreshi :-)
Editoval 22 (23. 8. 2011 23:38)
- ic
- Člen | 430
Taky myslím, že výsledek by na takovém stroji měl být mnohem lepší…
pokud nejde třeba o údaj po promazání veškeré cache (RobotLoader,
překlady šablon, …).
Je tu ale jedno téma, kde se řešily rychlosti hostingů, ale taky se tam
vyskytlo pár zátěžových testů… https://forum.nette.org/…te-i-bez-nej
… to by možná mohlo pomoct.
- B30wu1f
- Člen | 7
Počkám až mi přijde notebook z opravny a zkusím na něm nainstallovat
MYSQL apache zařízení a poté zkusim framework.
Notebook je rychlejší než můj PC. Zatím díky za replies.
Xampp dokonce hlásí 9 749.8 ms :D já už nevim.. opraví se prodleva když nainstalluju jen ty programy na apache a mysql bez balíčků?
Editoval B30wu1f (24. 8. 2011 16:20)
- dejvid
- Člen | 11
Potvrzuji existenci problému s pomalým Nette 2 beta (24.8.2011) na předem připravených WAMP balíčcích. Testoval jsem to s XAMPP a EasyPHP, obojí se stejným výsledkem (1300ms latence při refreshi stránky). Při poctivé instalaci jednotlivých komponent zvlášť to funguje normálně (~100ms u non-minified verze).
- Tharos
- Člen | 1030
Není součástí těch balíčků třeba i nějaký předinstalovaný debugger? Co si vzpomínám, tak například starší verze XDebugu uměly udělat podobné záseky, kdy server čekal pár sekund právě na nějakou debugovací session.
Pokud by byl přítomen například předinstalovaný XDebug v podobě Apache modulu, vyzkoušel bych jej deaktivovat.
- bojovyletoun
- Člen | 667
Mám pocit, že v poslední verzi PHP **(5.3.3 – 5.3.5–
aktuálně 5.3.9) se značně **zpomalilo include.
Načtení minified nette verze trvá 80ms (které se nezapočtou do Debug
panelu)), běh jednoduché aplikace(routa, presenter, latte) 150ms.
O neminifikované verzi škoda mluvit: aplikace běží 600ms.
Můžete někdo potvrtit toto? Procesor mám 2core 2Ghz, zkoušeno i na
ramdisku. xdebug zpomaluje maximálně o 10%.
EDIT: Chyba bude v php.ini – dám vědět.
Editoval bojovyletoun (20. 1. 2012 22:12)
- bojovyletoun
- Člen | 667
Takže POZOR:
- pokud smažete open_basedir z php.ini, vaše aplikace budou astronomicky rychlé (naprosto stejně jako s minifikovanou verzí).
- doba běhu se sníží ze 180ms [500ms nemini verze] na 120ms(pro obě verze). (ještě se zaplým xdebug).
- výše jsou uvedené celkové časy, tedy včetně include loaderu. Samozřejmě čas v debugbaru se liší: u mini verze je většina času(80ms) vynaložena na ten první include, takže v panelu se ukáže krásných 30ms, zatímco u plné verze 110ms.
- Jenže mě znepokojuje právě chybějící ochrana souborů. (Vždy si vzpomenu na callbackPanel, který mi chtěl smazat c:/ – chyběl tam kus stringu v cestě). Nevíte jak zabezpečit toto bez open_basedir pod windows 7, apache 2?
PS: mám pocit, že jsem objevil ameriku.
PS2: když vypnu xdebug a zapnu eaccelerator, tak je to fofr, ze 12Oms na 50ms!
Editoval bojovyletoun (20. 1. 2012 23:06)
- Caine
- Člen | 216
Mě se zas občas stává (nejen na localu), že z ničeho nic je průměrná doba spouštění několikanásobná (např na localu mam cca 250ms, pak se to najednou zvedne na 1000+ms) a nějakou dobu se to drží… Přitom si nejsem vědom, že bych měnil nastavení, který by s tim souviselo (cache, robotloader, atp)..
- bojovyletoun
- Člen | 667
No takže když se mi podařilo vytunit rychlost, tak pak se dá sledovat relevantně, co ja jak pomalé. Aktuálně tedy slabší místa jsou (hlavní)
- generování odkazů (mnoho)
- renderování formulářů
- vykreslování hoodně dat do debugbaru (při velké rekurzi:))
- … (méně výrazné:)
- přístup ke kontejneru
- získávání anotací
PS: ještě k velikosti APC. Pokud vyvíjím intenzivně (spustím
10 velkých projektů(do počtu souborů) na gitu (DOctrine SAndbox,
Quickstart, CMS, NanoCMS,venne, wordpress, CoolMS, examples), tak to zabere
nějakýc 150MB apc paměti a 700 souborů.
Takže to chce nastavit vhodně
apc.shm_segments,apc.shm_size,apc.num_files_hint
osobně mám 2000 souborů, 3*128MB.
Editoval bojovyletoun (21. 1. 2012 18:41)
- bojovyletoun
- Člen | 667
PS. ještě když jsem u té rychlosti. tak použíjte tuto verzi APC (pro
windows) 3.1.9 (‚locking_type‘ ⇒ ‚Windows Slim RWLOCK (kernel)‘) je
stabilně nejrychlejší než 3.1.8 (‚locking_type‘ ‚Windows Slim RWLOCK
(native)‘) a 3.1.5 (lock=filelock)
http://dev.freshsite.pl/download.html
Ps: akorát se nemohu zbavit při restartu(service) apache hlášky Operation Failed , podle eventlogu(win) jde o appcrash. Děje se to jen při zapnuté apc a v php jako modulu. pokud dám nejdřív stop a pak start tak to jde ok.
a ještě: jde spouštět apc v fastcgi, aby se sdílela pamět? mám win7, apache 2.4