Stejná komponenta volaná v rámci jedné šablony vícekrát

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
wotaen
Člen | 82
+
0
-

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)

vlki
Člen | 218
+
0
-

Ú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?:)

wotaen
Člen | 82
+
0
-

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

redhead
Člen | 1313
+
0
-

cache?

wotaen
Člen | 82
+
0
-

redhead napsal(a):

cache?

Jo cache jo, to sice řeší problém s performancí, ale někde jinde, než bych si to představoval. Co když se budou články měnit rychle nebo to bude něco jiného, co se přirozeně rychle mění a kde bude užitečnost cache klesat?

David Grudl
Nette Core | 8227
+
0
-

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
+
0
-

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
+
0
-

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…