Joomla! konzole ladění chyb - Nalezeno x duplikátů!
10. dub 2019 09:08 #139797
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
10. dub 2019 13:16 #139799
MiniJoomla! - www.minijoomla.cz - eshop s rozšířením Joomla/VM
Email Manager - aplikace na správu šablon emailů pro VirtueMart
Easy Feeder - aplikace na generování XML/CSV feedů a napojení na ERP pro VM
PragueClassicconcert - portál pro prodej vstupenek na systému Joomla
Odpověď od Rudolf
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ž přeji správnou a long journey
MiniJoomla! - www.minijoomla.cz - eshop s rozšířením Joomla/VM
Email Manager - aplikace na správu šablon emailů pro VirtueMart
Easy Feeder - aplikace na generování XML/CSV feedů a napojení na ERP pro VM
PragueClassicconcert - portál pro prodej vstupenek na systému Joomla
10. dub 2019 13:18 #139800
To zní škodolibě
Odpověď od marvays
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ě
10. dub 2019 15:06 #139802
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
Odpověď od marvays
Cony napsal:
Spíš zkušeněmarvays napsal: To zní škodolibě
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
10. dub 2019 16:15 - 10. dub 2019 16:25 #139803
Phoca Cart - www.phoca.cz/phocacart - e-shop, e-commerce
Phoca Gallery - www.phoca.cz/phocagallery - obrázková galerie
Phoca Download - www.phoca.cz/phocadownload - stahování souborů
Phoca Guestbook - www.phoca.cz/phocaguestbook - guestbook
Odpověď od H13
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 Cart - www.phoca.cz/phocacart - e-shop, e-commerce
Phoca Gallery - www.phoca.cz/phocagallery - obrázková galerie
Phoca Download - www.phoca.cz/phocadownload - stahování souborů
Phoca Guestbook - www.phoca.cz/phocaguestbook - guestbook
10. dub 2019 17:15 #139808
Odpověď od Cony
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á...
10. dub 2019 17:22 #139809
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é.
Odpověď od marvays
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é.
10. dub 2019 18:35 #139810
Phoca Cart - www.phoca.cz/phocacart - e-shop, e-commerce
Phoca Gallery - www.phoca.cz/phocagallery - obrázková galerie
Phoca Download - www.phoca.cz/phocadownload - stahování souborů
Phoca Guestbook - www.phoca.cz/phocaguestbook - guestbook
Odpověď od H13
Phoca Cart - www.phoca.cz/phocacart - e-shop, e-commerce
Phoca Gallery - www.phoca.cz/phocagallery - obrázková galerie
Phoca Download - www.phoca.cz/phocadownload - stahování souborů
Phoca Guestbook - www.phoca.cz/phocaguestbook - guestbook
10. dub 2019 18:42 #139811
MiniJoomla! - www.minijoomla.cz - eshop s rozšířením Joomla/VM
Email Manager - aplikace na správu šablon emailů pro VirtueMart
Easy Feeder - aplikace na generování XML/CSV feedů a napojení na ERP pro VM
PragueClassicconcert - portál pro prodej vstupenek na systému Joomla
Odpověď od Rudolf
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).
MiniJoomla! - www.minijoomla.cz - eshop s rozšířením Joomla/VM
Email Manager - aplikace na správu šablon emailů pro VirtueMart
Easy Feeder - aplikace na generování XML/CSV feedů a napojení na ERP pro VM
PragueClassicconcert - portál pro prodej vstupenek na systému Joomla
10. dub 2019 21:33 #139819
Odpověď od Cony
Ok, sorry, četl jsem moc rychleH13 napsal: U třech instancí pluginu v jednom článku
Nejnovější příspěvky
