Doba odezvy serveru je příliš dlouhá
- ali
- Člen | 342
Doctrine:
- pokud mas vetsi mnozstvi zaznamu v DB, ktere strankujes, tak doporucuju tento postup pro nastaveni paginatoru
$paginator = new Doctrine\ORM\Tools\Pagination\Paginator($qb->getQuery());
$paginator->setUseOutputWalkers(FALSE);
$this["paginator"]->setItemCount($paginator->count());
- dale bych doporucil u OneToMany a ManyToMany nastavit fetch=„EXTRA_LAZY“, pri velkem objemu dat tak muzes urychlit ukladani novych zaznamu
- Jan Tvrdík
- Nette guru | 2595
@Landsman Buď můžeš zkusit náhodně zrychlovat různé částí aplikace a doufat, že to dobře tipneš. Nebo to můžeš změřit přes Blackfire. Volba je na tobě.
- David Matějka
- Moderator | 6445
Je ten problem pouze na serveru, nebo i na lokalu? Jaky system bezi na VPS?
Zkus si to pripadne spustit na lokalu s dumpem produkcni db (jestli je nejaka vetsi).
- iguana007
- Člen | 970
@Landsman tak si nad tím pusť nějaký profiler, potom by to už mělo být snadné. Buďto přes Blackfire, jak už ti radil @JanTvrdík nebo si vyber něco tady: http://stackoverflow.com/…a-php-script
Editoval iguana007 (1. 8. 2016 14:14)
- Jan Tvrdík
- Nette guru | 2595
@Landsman Bez konkrétního příkladu jde těžko poradit. Většinou
stačí zajistit, že máš všechny informace pro sestavení URL v
Application\Request
, tj. nemusíš pak pro každý odkaz poslat
dotaz do DB.
Pokud to chceš hodně zoptimalizovat, tak zvaž, jestli se ti nevyplatí
přidat třeba vlastní makro {productLink $product}
, který
vygeneruje odkaz na produkt mnohem rychleji než když každý odkaz musí
projít přes presenter a router. Alternativně (pokud nechceš měnit kód
šablon) můžeš přetížit existují makra link
,
plink
a n:href
, aby dělali to samé jako
{productLink}
na základě statické analýzy v době
kompilace.
- Landsman
- Člen | 152
@JanTvrdík To zní fajn.
Vidím to jednoduše tak, že dám před kategorie a detaily zboží prefix pro router, čímž pozná, o jaký modul, presenter jde a nebude muset probírat to kvantum adres z databáze. 404 pak vytvořím až uvnitř presenteru. Tím by se tomu mělo značně ulevit.
Ještě mě zajímá docela ta optimalizace Doctrine. Také mě láká zkusit Redis.
- Jan Tvrdík
- Nette guru | 2595
Vidím to jednoduše tak, že dám před kategorie a detaily zboží prefix pro router
To zrychlí jenom volání match
, ne? Myslel jsem, že máš
problém s generováním hodně odkazů.
- Jan Tvrdík
- Nette guru | 2595
Jn, to bohužel vypadá, že je to routování vyřešeno úplně špatně. Počet route objektů by měl být minimálně 100× menší.
- Jiří Nápravník
- Člen | 710
Landsman napsal(a):
Zde je výstup testu: https://blackfire.io/…d84e02/graph
Ukaz App\RouterFactory::createCatalogRouter
- Landsman
- Člen | 152
Souhlas je to úlet. Předělám to na ty prefixy, aby se do routeru nemuseli cpát ty individuální adresy.
Dotaz: lze nějak zapsat pravidlo pro subdoménu? Líbilo by se mi: shop.domena.cz ⇒ router by hned věděl že jde o shop kategorie a už by řešil jen jakou. A nasměroval bych subdoménu jako alias.
Editoval Landsman (2. 8. 2016 17:08)
- Jan Tvrdík
- Nette guru | 2595
@Landsman Myslíš něco jako https://github.com/…ull/43/files#… ? V určitých situacích může být užitečný i https://github.com/…tatic-router
- Landsman
- Člen | 152
Router poladěný, jsme na cca 474 ms z čehož 68.3% žerou funkce file_get_contents(), které se používají na načtení SVG obrázků, což mě dost zaskočilo.
Nelze je lépe cachovat?
EDIT:
Vyřešil jsem to vytvořením custom makra svg v kterém otevírám ikony přes fopen() a voala, jsme na 158 ms, tedy 86% zlepšení! Ještě tam jsou limity v porovnávání GPS vzdáleností, ale to prostě trvat bude.
Dost mě zaujalo však toto doporučení:
You should dump optimized Composer autoloader
metrics.composer.autoload.find_file.count 242 <= 50
Editoval Landsman (5. 8. 2016 2:54)
- Martk
- Člen | 661
Composer pro autoloading nepoužívá jen classmapu, ale i jiné autoloadery (psr-0, psr-4), které jsou pomalejší. Řešení je jednoduché převést všechny psr-0 a psr-4 na classmap.
Příkaz pro composer: composer dump-autoload -o
potom je ještě přepínač -a, který implicitně zapíná -o. Rozdíl je v tom, že když je zapnut, tak se načítají třídy jen z classmapy a když není nalezeno, tak se neprovádí další nahrávání v rámci composeru (psr-0, psr-4).
Anglický článek: http://mouf-php.com/…-performance
Editoval Antik (5. 8. 2016 8:37)
- Landsman
- Člen | 152
Antik napsal(a):
Composer pro autoloading nepoužívá jen classmapu, ale i jiné autoloadery (psr-0, psr-4), které jsou pomalejší. Řešení je jednoduché převést všechny psr-0 a psr-4 na classmap.
Příkaz pro composer:
composer dump-autoload -o
potom je ještě přepínač -a, který implicitně zapíná -o. Rozdíl je v tom, že když je zapnut, tak se načítají třídy jen z classmapy a když není nalezeno, tak se neprovádí další nahrávání v rámci composeru (psr-0, psr-4).
Anglický článek: http://mouf-php.com/…-performance
Díky za informace. Zkusil jsem a přihoršilo si to o cca 10 ms, doporučení každopádně zmizlo, tak nevim.
- Landsman
- Člen | 152
@Antik Také mi připadalo divné, jiné změny však neproběhly. Ještě postuduji jak efektivněji porovnávat gps vzdálenosti míst, to tam nyní baští nějaký čas.
Btw: Co ten file_get_contents()? Proč to latte necachuje result, když jde o lokální soubor @DavidGrudl? Hodně lidí doporučuje zobrazovat svg obrázky právě takto.
- Martk
- Člen | 661
Makro se převede do php kódu a to se zacachuje (nadále se neprovádí převedení makra), tzn. funkce file_get_contents() se vykonává. Řešením může být cachování v šablonách.
{cache svg}
{svg first}
{svg second}
{/cache}
Pozor dávej obzvláště na invalidaci.