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
Ř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
Pro možnost přispívání do fóra je nutné: Přihlásit se nebo Vytvořit účet.
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ě.
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ě.
Pro možnost přispívání do fóra je nutné: Přihlásit se nebo Vytvořit účet.
Pro možnost přispívání do fóra je nutné: Přihlásit se nebo Vytvořit účet.
Pro možnost přispívání do fóra je nutné: Přihlásit se nebo Vytvořit účet.
Pro možnost přispívání do fóra je nutné: Přihlásit se nebo Vytvořit účet.
Pro možnost přispívání do fóra je nutné: Přihlásit se nebo Vytvořit účet.
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
)
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
) Phoca Gallery - http://www.phoca.cz/phocagallery - obrázková galerie (Joomla!)
Phoca Guestbook - http://www.phoca.cz/phocaguestbook - kniha návštěv (Joomla!)
Phoca Download - http://www.phoca.cz/phocadownload - stahování souborů (Joomla!)
Phoca Cart - http://www.phoca.cz/phocacart - e-shop,...
Pro možnost přispívání do fóra je nutné: Přihlásit se nebo Vytvořit účet.
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á...
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á...
Pro možnost přispívání do fóra je nutné: Přihlásit se nebo Vytvořit účet.
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é.
Pro možnost přispívání do fóra je nutné: Přihlásit se nebo Vytvořit účet.
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
Phoca Gallery - http://www.phoca.cz/phocagallery - obrázková galerie (Joomla!)
Phoca Guestbook - http://www.phoca.cz/phocaguestbook - kniha návštěv (Joomla!)
Phoca Download - http://www.phoca.cz/phocadownload - stahování souborů (Joomla!)
Phoca Cart - http://www.phoca.cz/phocacart - e-shop,...
Pro možnost přispívání do fóra je nutné: Přihlásit se nebo Vytvořit účet.
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).
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).
Pro možnost přispívání do fóra je nutné: Přihlásit se nebo Vytvořit účet.
Pro možnost přispívání do fóra je nutné: Přihlásit se nebo Vytvořit účet.
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.
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.
Pro možnost přispívání do fóra je nutné: Přihlásit se nebo Vytvořit účet.
