Joomla! konzole ladění chyb - Nalezeno x duplikátů!

Ano, duplikát SQL dotazu znamená přesně to, aplikace se dvakrát (nebo vícekrát) zeptá do DB na úplně stejnou věc.
Databázi to samozřejmě zbytečně zatěžuje, nelze ale jednoznačně říct jak moc. Na hostingu s omezeným počtem připojení do DB by to mohlo způsobovat problémy při více návštěvnících.

Jinak i 80 dotazů mi přijde pořád poměrně hodně.

marvays napsal: To zní škodolibě

Spíš zkušeně

Tady se prostě musíš podívat na konkrétní dotazy, co se duplikují.

Někdy se prostě stane, že se dotaz dostane do smyčky a pak je potřeba zjistit, jestli se to nedá udělat tak, že si vytvoříme statickou proměnnou a pokaždé, když se někdo zeptá na daný dotaz (z jakéhokoliv místa), podíváme se, jestli už data neexistují, pokud ano, vrátíme existující data, pokud ne, zeptáme se databáze. To může ale taky být teoreticky nebezpečné, pokud se v jednom skriptu mění data v databázi, ... To znamená, že s v nějakém okamžiku ptáme na nějaká data, která jsme si ale díky šetření uložili dříve a ty uložená data nejsou aktuální.

Pak se taky může stát, že i opakovaný dotaz je šetrnější, než nějaký složitý komplikovaný dotaz, který by nahrával všechna data najednou a pak je postupně rozděloval.


Příklad:

a) Vybírám data po jednom, protože nevím, kolik instancí bude. Tak se třeba stane, že jeden dotaz padne pětkrát za sebou.

Opak:

b) Jedním dotazem vyberu kompletně všechna data na jednou a pak podle potřeb dodávam těm, co se na ně ptají. Například vyberu 100 položek a pak těm pěti, co se na ně ptají, ty data přidělím. A ano, těch zbylých 95 bylo zbytečně vybráno, s tím, ale, že jsme zase na druhou stranu měli jen jeden dotaz.

Co tím chci říčt, že kolikrát i 10x opakovaný dotaz může být časově a paměťově méně náročnější než jeden dotaz, který ale musí získat všechna data a rozdělovat je poté podle potřeby.

Je to o tom, zjistit, jestli spíš "zatížíme" PHP skript nebo SQL dotazy.

Tedy, i když se občas nějaký SQL dotaz duplikuje, nemusí to být takové zlo, jako když se duplikují části zdrojového kódu.

Nestačí jen vědět, že se dotaz duplikuje, ale bohužel musíš zjistit, co je to za dotaz, odkud se volá a porovnat ho s variantou jednoho dotazu. A to se těžce dělá, protože sice dobře porovnáš dotazy do databáze, ale porovnat je komplexně i s PHP skriptem bude složitější (co ušetříme na SQL dotazech, vydáme zase v PHP, apod.)

Navíc se ještě nacházíme v systému, který se skládá z mnona malých částí, takže např. komponenta se zeptá na úplně ten stejnej dotaz jako nějaké dva nezávislé moduly. Tím vzniknou tři stejný dotazy, ale toto se bohužel dopředu nedá dobře ošetřit (když nikdo dopředu neví, jaká kombinace modulů/pluginů/komponent na stráce poběží)

Příklad z praxe:

- dáš si 3 instance content pluginu do článku, tak ten pravděpodobně udělá 3 stejný dotazy (jestli by bylo šetrnější, aby se první instance zeptala na vše a pak postupně rozdávala ostatním instancím, to dopředu nikdo nedokáže odhadnout )

Ale on ten content plugin neudělá 3 stejný dotazy, pokaždý se bude ptát na jiný článek.

Duplikace dotazů se samozřejmě stát může, často to asi bude při zobrazení jednoho článku (produktu nebo čehokoliv) na různých místech (obsah, modul atd.). Ale 168 duplicitních dotazů na jedno a to samé ID na homepage od Quix mi přijde trošku moc

Každopádně je to hlavně věc vývojáře toho rozšíření, popř. šablony, našinec s tím už moc neudělá...

Cony napsal: Ale on ten content plugin neudělá 3 stejný dotazy, pokaždý se bude ptát na jiný článek.

U třech instancí pluginu v jednom článku

H13 napsal: U třech instancí pluginu v jednom článku

Ok, sorry, četl jsem moc rychle