Pomalé načítání aplikace – jak zrychlit

ondrej256

Dobrý den,

nevím jistě jeslti problém souvisí přímo s nette, ale u jiných aplikací (wordpress) mně to nedělá.

Jedná se o to, že používám wamp sever a než se v mojí aplikaci načte jedna stránka tak to trvá 5–10 sekund. Dotazy nad databází zaberou 200 ms, zbývající čas se ztrácí neznámo kam.

Neděje se to jen u jedné aplikace, ale u více. Někdy se stane, že se stránka načte ihned, takže to není uplně pravidelné chování.

Nevíte čím by to mohlo být?

David Kudera

Neděje se to třeba poté, co něco upravíš v kódu? Může se to stát po úpravě šablony (nette ji znovu zkompiluje a uloží do cache) nebo např. při změně konfigurace (stejný případ)..

David Grudl

Někdy pomůže změnit v připojení k DB localhost na 127.0.0.1

Onda

Ahoj já měl podobný problém a pomohlo mi že jsem odinstaloval balíky jako vertrigo,wamp a začal používat čistý apache, php a najednou mám místo 1500–3000ms nějakých 150–300s někdy i méně. Takže opravdový rozdíl.

David Kudera

No a pokud nic nepomůže a bylo by to v php, tak můžeš zkusit nějaký profiler. Třeba webgrind

chap

Ahoj,
mám také trochu problém s během aplikace. Doba requestu se pohybuje někde nad 1s. Když jsem spustil timer na začátku bootstrapu a pak v startup basepresenteru, tak mi vyšlo nějakých 800ms. Výsledky z XDebugu jsou nějaké vidět zde: http://i.xomf.com/wdgwv.png a http://i.xomf.com/nqwhk.png

Z toho nejsem zcela moudrý, ale vypadá to buď na špatnou práci s inicializací služeb, nebo neustálou kontrolu anotací? Prosím nakopněte mě, jak to zlepšit – případně, jak zjistit něco konkrétnějšího. Díky.

Jan Tvrdík

Podle profileru se většinu času čeká na Doctrine. Mimo Doctrine koukni proč se volá tolikrát getDeclaringClass(), file_exists a filemtime.

David Matějka

@chap vypada to, ze mas spatne nastavenou cache. Pouzivas kdyby/doctrine?

chap

Ano Kdyby/Doctrine … V neonu jsem neměl definováno pro doctrine cache a anotations viz:

doctrine:
	metadataCache: default
	queryCache: default
annotations:
	cache: default

V produkční verzi jsem měl toto stejné jen místo default mám xcache – ale rychlost byla téměř stejná. Po přidání default cache nepozoruji žádnou změnu.

Filip Procházka

Pokud chceš reálný čísla, tak si zkus na test zapnout aplikaci v produkčním módu

$configurator->setDebugMode(FALSE);

Smázni cache, obnov stránku a změř druhý request (s vygenerovanou cachí).

Na localhostu je to s doctrinou často dost bída. Protože se musí kontrolovat, jestli jsi nezměnil entity a když jo, tak je refreshovat. Pak je ještě možné, že tam děláš něco fakt blbě a nutíš doctrinu načítat věci které k normálnímu pageloadu vůbec nepotřebuješ. Viděl jsem už v pár aplikacích, jak někteří například hledají metadata jedné třídy a vytáhnou kvůli tomu metadata úplně všech entit z cache – to taky něco stojí.

To s těmi lexery nasvědčuje, že máš fakt nějak hodně divně nastavenou cache, zkus ještě natvrdo nastavit

doctrine:
	debug: off

tohle způsobí, že doctrina přestane cache ukládat jako závislou na entitách a nebude tedy vůbec při načítání kontrolovat jestli se soubory změnily. Zrychlí aplikaci, ale budeš si muset invalidovat cache ručně. V produkčním módu je tohle samozřejmě vypnuté :)

To vysoké množství getClassMetadata zase naznačuje neoptimální použití. Doctrina tuhle metodu hodně volá když hydratuje a flushuje data. Doctrina se v první řadě chová „korektně“ a až v druhé řadě efektivně. Nepřekvapilo by mě, kdybys například pokládal velice neefektivní DQL dotaz. Pokud bys byl fakt šikovnej, tak to jde napsat až tak blbě, že jedním dotazem s pár joinama klidně zabiješ několik vteřin.

chap

tak měření na lokalhostu v produkčním módu vyšlo na 2.8s vs 1.4s. Debug off nemělo nějaký zvláštní význam. DQL s joinem volám až v presenteru – ale měl jsem přes vteřinu už ve chvíli kdy je volán startup presenteru. Nakonec jsem odhalil jeden zádrhel – mám tabulku nastavení, kde je textový klíč a hodnota dané konfigurace. Konfiguraci si načítám v každém requestu a vytvářím stdClass, která obsahuje jednotlivé vlastnosti. Měl jsem tam drobnou chybku, která mi nagenerovala jednu vlastnost v tabulce do nějakých 4000 záznamů (používám result cache). Takže jsem na v každém requestu načetl všechny záznamy, které jsem přeiterovával. Teď mám jeden request na cca 650ms. Možná bych si ještě představoval o trochu méně ale takhle zatím asi uspokojivý výsledek.

Možná jen ještě jeden dotaz. V aplikaci používám takovou obezličku (z historických důvodů), kdy v basepresenteru si injectnu všechny facade, abych je měl z pár komponent přístupné pře $this->presenter->fooFacade->doSomething(); Tak jen dotaz, zda je tento přístup také možná příčina dlouhého načítání?

Jan Tvrdík

v basepresenteru si injectnu všechny facade, (…) je tento přístup také možná příčina dlouhého načítání?

Ano, to bys rozhodně neměl dělat.

greeny

Pokud facady potřebuješ v komponentě, tak si je přece dej přímo do té komponenty, ne?

chap

greeny napsal(a):

Pokud facady potřebuješ v komponentě, tak si je přece dej přímo do té komponenty, ne?

jojo už jsem to předělal :) ono to mělo historický důvod – dříve jsem to dělal trochu dle svého a nechtělo se mi to už v projektu předělávat. Nakonec jsem to stejně udělal, abych měl dobrý pocit :)