Může počet presenteru, servis a továrniček výrazně ovlivnit rychlost aplikace?
- Sofiosko
- Člen | 7
Už nějakým tím rokem pracuji na projektu, který za svůj život šíleně nabobtnal a rychlost začala značně pokulhávat. Rozhodl jsem se proto s tím něco udělat.
Po spoustě optimalizací jsem to stáhnůl na 400ms po
cachnuti DI containeru bez vykreslení obsahu (localhost), což je strašně
moc.
Pro porovnání:
- Testovaný projekt má 90 presenteru a přes 400 servis a jede okolo 400ms
- Čistá instalace nette mi jede okolo 30–40ms
- Malý projekt o 10 presenterech a cca 10–20 servisách jede okolo 40–50ms
Což není tak šílený rozdíl (mezi čistým a malým projektem) abych mohl podezřívat velikost aplikace ale i přesto jsem se rozhodl zkusit celý projekt od začátku sestavit a to tak, že jsem nevkládal žádné servisy, továrničky ani presentery, které nebyly potřeba pro rozjetí projektu a dostal se na 200–230ms.
U obou aplikací jsem porovnával identický presenter jenž rozšiřoval ten samý BasePresenter a ve výsledku injectovali úplně to samé co reálně využili.
U původního pomalejšího projektu jsem ještě zkusil v configu zakomentovat servisy, které presenter nepoužíval ale narazil jsem na problém. Pokud existují fyzicky neaktivní presentery, musí být zaregistrované i servisy jenž injectují.
Otázka tedy zni: Je možné, že takovéto velké množství presenterů způsobí rapidní zpomalení aplikace i po cachnutí DI containeru? Nebo bych měl dále hledat chybu v kódu?
Děkuji a doufám, že nepřivolám dav s vidlemi a loučemi :D
Editoval Sofiosko (17. 11. 2019 1:02)
- JiriSlischka
- Člen | 9
Viz co psal CZechBoY, můžeš mít v constructoru logiku. Která se
spouští zbytečně.
Jedním z případu jsou třeba CLI commandy. Pokud definuješ název commandu
přes configure metodu. Tak se musí každý CLI command vytvořit,
aby se zjistilo jaký název ten command má.
Pokud ten název přesuneš do
public static $defaultName = 'business:charge-excesses';. Tak se ti
zrychlí načtení commandů. A reálně se vytvoří pouze ten jeden command
(a k němu dané služby) a ne všechny co v appce máš.
To může appku hodně zpomalit protože se může vytvářet DB spojení,
session, rabbit atd.
- Felix
- Nette Core | 1188
Zkusil bych si zapnout Blackfire (https://blackfire.io/) a udelat request na homepage a pak nejakou statickou stranku, kde by nemel byt zadny vykon.
Z moji zkusenosti, dost zere navesovani eventu na cokoli. Tak se mrkni, jestli tam nemas nejakou slozitou logiku.
- Marek Bartoš
- Nette Blogger | 1167
Při testování se ohlížej též na to, zda máš zapnutý debug mód. Při debugu se kontrolují změny v souborech a též zapnuté debug panely mohou trvat podstatnou část requestu.
Pokud trvá načtení DI kontejneru samo o sobě, tak nejspíš jde o konfiguraci OPcache.
Nejsnadněji se to dá vyčíst ze zmiňovaného Blackfire
- Sofiosko
- Člen | 7
@CZechBoY Díky za radu, zkontroloval jsem každý konstruktor v aplikaci a našel 2 výskyty, které sice nezpomalovali testovací stránku ale někde v aplikaci určitě jo.
@JiriSlischka Díky, přivedl si mě na dvě věcí které pomohli aplikaci urychlit. Skrze klíčove slovo „configure“ jsem narazil na metodu, jenž upravovala šablony a zpomalovala je a také jsme měli v routeru CLI továrničku zastaralou, nepoužívanou, která žrala 20ms při každém requestu
@Felix @Mabar O blackfiru jsem již slyšel ale nikdy jsem se ktomu neměl. Na vaše doporučení jsem to teda rozchodil a zde je odkaz https://blackfire.io/…cd10d5/graph nebo https://blackfire.io/…371e88/graph a po všech úpravách jsem dokázal stahnout čas aplikace na ~270ms díky blackfiru.
Což je mnohem lepší ale stále to není ono. Je možné z toho odkazu vysledovat ještě něco podezřelého? Mě připadá podezřelé že vkládání souborů z vendora on demand žere 80ms.
Editoval Sofiosko (18. 11. 2019 10:00)
