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

Ahoj.
Řeším problém s jedním webem. jde o to, že z nějakého důvodu strašně zatěžuje databázi. Už druhý den se snažím přijít na to, co tam hapruje. Oto hůř, že se jedná o eshop. Eshopy stavím z 90% stejně a problém s vytížením je jen tady.

V ladění chyb jsem narazil na zajimavou věc. Pagebuilder Quix má hodně duplikátů.

Umíte mi prosím jednoduše vysvětli, co ty duplikáty vlastně znamenají a jestli to má nějaký vliv na zatížení?
Já si to představuju tak, že tato komponenta 21x vstoupí do databáze pro stejnou informaci, nebo vykoná 21x stejnou operaci. Což dle mé blažené nevědomosti znamená, že to zbytečně zatěžuje provoz.

Uvedený příklad je na jednoduchou html stránku s obchodníma podmínkama, jen napsanou v tom builderu

Když to srovnám se stejným html obsahem, jen vloženým v klasickém článku

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ě.

Cesta k úspěšnému vytváření eshopů na Joomla je trnitá a businessově úspěšné eshopy se liší od těch skládaných běžnými adminy právě v těchto maličkostech a hlavně znalostech.

Tož přeji správnou a long journey

Rudolf napsal: Cesta k úspěšnému vytváření eshopů na Joomla je trnitá a businessově úspěšné eshopy se liší od těch skládaných běžnými adminy právě v těchto maličkostech a hlavně znalostech.

Tož přeji správnou a long journey

To zní škodolibě

marvays napsal: To zní škodolibě

Spíš zkušeně

Cony napsal:

marvays napsal: To zní škodolibě

Spíš zkušeně

Jasně. Myslel jsem to v legraci. Mám vás rád kucí a jen v dobrém. Líbí se mi, jak Rudolf odpověď jen naťukne, přitom dá najevo, že to má už dávno za sebou a vychytaný a že mi to nechce prozradit

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: 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á...

No dyť. Copak já jsem nějaký programátor? Já přešel na joomlu z grafického studia v tiskárně. Raději se budu věnovat webovému designu. Proto jsem u joomla, protože to je modulární systém a borci jako vy ty rozšíření napíšou a prodají. Já už si jen sladím grafiku

Jen hold asi ti indiáni na tu čistotu práce moc nedají a čím dál víc zjišťuju, že to jsou pěkní břídilové.

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

Vítej v klubu

Za mě dobrý programátor je RegularLabs, ten to má vychytané nejen kvalitou kódu ale i z marketingového hlediska. Jak jen třeba má propracovaný systém instalací a upgradů a automatických informací o verzích.

A pak Viktor z ES, který naprogramoval Easy Virtuemart, protože seděl vedle mne

Zpět k debugu - Má pravdu Honza - je to skládačka, takže počty dotazů a jejich oprávnění je bohužel nutno obětovat na oltář jednoduchosti vytváření obsahu v administraci.

Pokud chceme lepší systém, tak už musíme přeprogramovávat a dostáváme se na pomyslnou cestu mezi skládačkou a programováním na míru. (pokud to zaplatí klient).

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

Ok, sorry, četl jsem moc rychle

Dobré ráno.
Potřebuju v "naší" věci tedy poradit, jestli mám tu komponentu Quix tolerovat, nebo se na ni vykašlat . . . . minimálně na stránkách eshopu.

Dále bych byl moc rád, kdyby jste mi doporučili nějaký "rychlý" modul košíku (nebo používáte ten originál VM?)

Jinak celé včerejší odpoledne a večer testuju stejnou kopii na různých hostinzích.