Stejná komponenta volaná v rámci jedné šablony vícekrát
- wotaen
- Člen | 82
Ahoj všichni, potýkám se s tímhle problémem…
mám šablonu, která vkládá 6× tu samou komponentu, jedná se o banner a
vždy se vybere náhodný banner, případně jiný typ, volání vypadá
takto
{control banner <typ>}.
Počítají se impressions, tj. po výběru banneru se přičte jednička
v db – jedná se o update a trochu to brzdí, vynásobte to 6 a už to
brzdí trochu více.
Řešení mě napadá několik, ale zajímalo by mě, jestli to umí nějak
řešit framework nebo si musím něco napsat. Případně jak to
řešíte vy…
Díky, Michal
Editoval wotaen (13. 11. 2009 13:45)
- wotaen
- Člen | 82
vlki napsal(a):
Úplně přesně nechápu, co ti tak zpomaluje načítání. Těch šest UPDATE dotazů na databázi?
Pokud ano, tak to udělej až po načtení stránky nějakým AJAXem, hm?:)
Jasně AJAX by šel použít, stejně jako nějaký queue mechanismus na straně serveru, který by ty updaty udělal naráz. Ten update je pomalý možná i kvůli serveru, nevím, ale můj problém je „obecnější“. Vadí mi, že způsob, který používám pro zobrazování komponent {control xyz}, které se vyskytují vícekrát v templatu mi teď generuje mnohem více dotazů než bych si představoval. A nemusí jít o triviální bannery. Třebas mám komponentu na zobrazení x novinek z databáze dle kategorie, ta kategorie je to jediné, co se mění, tj. ideální kandidát na komponentu {control zobraz_clanek $kategorie}, super. Ale třebas ten dotaz na výběr článků je složitý a zabere hodně času, co teď? Volat ho x krát, podle toho kolikrát použiju tu komponentu? Nebo použít jiný mechanismus, nějaké přednačítání, nebo tak něco…nevím
- David Grudl
- Nette Core | 8129
V případě těch UPDATE je to řešitelné poměrně snadno: během
kreslení stránky si jen poznamenáváš, které ID updatnout a po dokončení
renderování zavoláš hromadný UPDATE. (tady je otázkou, jak vyvolat něco
po renderování, šlo by možná využít Application::$onShutdown
nebo destruktor, nebo vymyslet něco lepšího).
V případě těch boxíků s novinkama je situace složitější v případě, že se o jejich podobě aplikace dozví až při samotném renderování stránky. Univerzálním řešením je samozřejmě kešovat HTML výstup boxíku, třeba na pár minut. Druhou možností je trik s „predikcí budoucnosti“ – po prvním neoptimalizovaném vykreslení stránky se vlastně dozvíme, jaké boxíky a obsahuje a jaká data potřebuje a tuto informaci si uložíme do cache/session (podle charakteru stránky). Při dalším vykreslování už dopředu víme, co bude šablona obsahovat a můžeme se na to připravit. No a třetí možností je předběžná analýza šablony, tj. zjištění, jaké boxíky se v ní nachází před samotným renderováním – tohle není zatím zcela nativně podporované (ale chystá se) a vyžaduje to od programátora udělat ručně.
- redhead
- Člen | 1313
právě, u těch článku a kategorií samozřejmě cache, u tohole je to horší.. řekl bych že framework tohle úplně neřeší.. Takže bych si napsal nějakou frontu a posílal to naráz v nějakou dobu.. //EDIT: viz první odstavec od Davida :)
Ale možná poradí něco lepšího ostatní.
Editoval redhead (13. 11. 2009 16:15)
- wotaen
- Člen | 82
Díky všem za vstupy, pro updaty jsem vytvořil jednoduchou queue, do které
si přidávám dotazy jako klíč (a místo …‚id=%i‘ mám ‚id in %l‘)
a jako hodnotu to idčko…ve shutdownu tu frontu projedu a zavolám sql které
potřebuju.
Na chvíli jsem přemýšlel o nějakém parsování šablon s predikcí, co
bude potřeba, ale velmi rychle jsem od toho upustil :) takže to opět nějak
kešuju.
Takže to vše zůstává na kešování na úrovni presenterů nebo
komponent…