Het forum voor de webwinkel eigenaar en bezoeker van webwinkels.

 
Gebruikersavatar
Ward
Berichten: 5343
Lid geworden op: 18 december 2010
Locatie: Eindhoven
Contacteer:

Re: Snelheid (of liever gezegd traagheid) webshop Opencart

05 juni 2015

Dus niets mis met de SQL query, vraag gewoon veel info uit grote tabellen.
We mogen het topic niet kapen, maar omdat dit ook de (suboptimale) performance van OpenCart raakt: je moet dan toch eens met EXPLAIN kijken naar het query execution plan.

Ik heb een vergelijkbare tabel voor pageviews van 100 MB met een half miljoen records. (Ga ik over de 100 MB, dan gooi ik de oude data weg.) Deze tabel heeft twee VARCHAR-kolommen: remote_addr voor het IP-adres en remote_host voor de bijbehorende hostnaam.

De kolom remote_host heeft geen index.
  SELECT COUNT(*) AS pageviews 
    FROM pageview_statistics
GROUP BY remote_host
ORDER BY pageviews DESC
Pageviews tellen kost dan dus ergens tussen 3,5 en 5 s:

• 4.9012 s
• 3.7270 s
• 3.5874 s

Met jouw 200 MB en 1 miljoen records in plaats van mijn 100 MB en 0,5 miljoen records kun je bij benadering een verdubbeling verwachten: de eerder genoemde 10 seconde.

De kolom remote_addr heeft wél een index:
  SELECT COUNT(*) AS pageviews 
    FROM pageview_statistics
GROUP BY remote_addr
ORDER BY pageviews DESC
En dan krijg je enkel en alleen door die index al een heel ander plaatje:

• 0.7584 s
• 0.5930 s
• 0.6655 s

Het punt is dat OpenCart op heel veel plaatsen géén INDEX heeft waar die wel gebruikt zou kunnen worden door de query optimizer van MySQL. Bij een FOREIGN KEY maakt MySQL automatisch een index, maar ook foreign keys zijn OpenCart vreemd: voor een JOIN over meerdere tabellen, moet dan een dubbele full table scan worden uitgevoerd met een subquery.

https://github.com/opencart/opencart/bl ... encart.sql

Tweede probleem dat je bij OpenCart kunt aanpakken is dat voor alle primaire sleutels een INT UNSIGNED wordt gebruikt. Dat maakt de keys in joins te groot: je hebt geen bijna 4,3 miljard klanten, 4,3 miljard adressen, 4,3 miljard categorieën, enzovoort, enzovoort. Het databaseontwerpbeginsel use the smallest key wordt dus met voeten getreden.
 
Dierenspeciaalzaak
Berichten: 689
Lid geworden op: 20 juni 2012
Locatie: Emmeloord
Contacteer:

Re: Snelheid (of liever gezegd traagheid) webshop Opencart

05 juni 2015

\ We mogen het topic niet kapen, maar omdat dit ook de (suboptimale) performance van OpenCart raakt: je moet dan toch eens met EXPLAIN kijken naar het query execution plan.
Laten we het daar op houden. De rest zit je namelijk nog steeds fout mee. Mijn SQL is met zekerheid niets mis mee. De situatie die jij schetst is ook niet vergelijkbaar. Waarom niet ga ik niet uitleggen, want dat is voor dit topic niet relevant en daarmee geef ik meer prijs van mijn database structuur, dan ik wil.

Wat betreft geen indexen in Opencart. Als dit zo is, dan is de oorzaak van het probleem wel heel duidelijk! De juiste indexen in een SQL database maakt inderdaad een wereld van verschil! Zelf had ik in mijn backend bepaalde zaken die heel traag waren. Bij nader onderzoek mistte ik ook een paar belangrijke indexes. Dat heeft een performance verschil geleverd op een bepaald proces van 20 seconden naar 0,5 seconden. Dus indexen controleren is allicht waar de oplossing zit voor TS!
Online Dierenspeciaalzaak is het adres voor uw huisdier.
Ohw en... Online Dierenspeciaalzaak BLOG!
 
Gebruikersavatar
Ward
Berichten: 5343
Lid geworden op: 18 december 2010
Locatie: Eindhoven
Contacteer:

Re: Snelheid (of liever gezegd traagheid) webshop Opencart

05 juni 2015

\ We mogen het topic niet kapen, maar omdat dit ook de (suboptimale) performance van OpenCart raakt: je moet dan toch eens met EXPLAIN kijken naar het query execution plan.
Laten we het daar op houden. De rest zit je namelijk nog steeds fout mee.
Zit ik met alles fout? Meen je dat nou serieus?

Voordat je zoiets stellig poneert, kun je allicht de beleefdheid opbrengen even naar het datamodel van OpenCart te kijken. Dat spreekt namelijk boekdelen:

https://github.com/opencart/opencart/bl ... encart.sql
 
jessewillem
Berichten: 4
Lid geworden op: 16 juni 2014
Locatie: Koudum

Re: Snelheid (of liever gezegd traagheid) webshop Opencart

05 juni 2015

...
Niet bij OpenCart. OpenCart gebruikt de outputbuffer (ob) alleen intern, bij het opbouwen van een MVC-view:

https://github.com/opencart/opencart/bl ... er.php#L29


Ook dan kan object buffering zorgen voor vertraging. Tussen ob_start() en ob_end_clean() hoeft maar ergens een trage functie te zitten en het gaat gewoon fout. Dat zou een SQL query kunnen zijn, inefficiënte lussen, ophalen van bestanden vanaf andere servers enzovoort.

Het idee van NOP Webdesign is natuurlijk ook een aanrader om uit te voeren op een lokale kopie van de site. Om dat eerst te doen is natuurlijk beter dan direct beginnen met het probleem op te zoeken op de live site. Zo kun je het een en ander uitsluiten, wat weer onnodig werk scheelt. Het kan bijvoorbeeld ook gewoon de server bij de hoster zijn waar de traagheid vandaan komt.
Advertentie

Met Shopify maak je zelf je eigen webwinkel dankzij meer dan honderd thema’s en de complete appstore. Shopify sluit ook goed aan op dropshippers. De software is technisch volledig SEO-geoptimaliseerd en biedt alle sociale media-integraties. Meer info op Shopify.com.

 
Gebruikersavatar
Ward
Berichten: 5343
Lid geworden op: 18 december 2010
Locatie: Eindhoven
Contacteer:

Re: Snelheid (of liever gezegd traagheid) webshop Opencart

05 juni 2015

Ook dan kan object buffering zorgen voor vertraging. Tussen ob_start() en ob_end_clean() hoeft maar ergens een trage functie te zitten en het gaat gewoon fout. Dat zou een SQL query kunnen zijn, inefficiënte lussen, ophalen van bestanden vanaf andere servers enzovoort.
Tussen ob_start() en ob_end_clean() doet OpenCart niets spannends:
ob_start();
require($file);
$output = ob_get_contents();
ob_end_clean();
Dat verdient niet de schoonheidsprijs, maar is wel een standaardtechniek om een string te gzippen. Winst is hier niet meer te behalen: de require van een template file heb je sowieso nodig.

Lokaal code en database tweaken is inderdaad verstandig. Maar netwerklatentie bij de provider los je er niet mee op. De TTFB is nu te laag, waardoor je zelfs zit te wachten bij een redirect van http:// naar https://.

Bovendien draait de site op een server met 100+ andere sites, dus kun je lokaal moeilijk de realistisch load testen.

Dan kun je nog beter vannacht om 3:00 uur de wekker zetten en kijken of de site nog steeds sloom is. Zo nee, dan weet je genoeg.

Dit probleem is vooral lastig omdat het niet slechts één probleem is. Hoge TTFB, geen client caching, slow queries en een complex template voor de render engine.
 
jessewillem
Berichten: 4
Lid geworden op: 16 juni 2014
Locatie: Koudum

Re: Snelheid (of liever gezegd traagheid) webshop Opencart

05 juni 2015

...
Tussen ob_start() en ob_end_clean() doet OpenCart niets spannends:
ob_start();
require($file);
$output = ob_get_contents();
ob_end_clean();
Dat verdient niet de schoonheidsprijs, maar is wel een standaardtechniek om een string te gzippen. Winst is hier niet meer te behalen: de require van een template file heb je sowieso nodig.
Het stuk code wat traag uitgevoerd wordt kan natuurlijk ook in de code zitten die tussen beide functies opgeroepen wordt met de require() aanroep. En dan draait het alsnog langzaam doordat er gewacht moet worden tot de object_buffer vol is.
Lokaal code en database tweaken is inderdaad verstandig. Maar netwerklatentie bij de provider los je er niet mee op. De TTFB is nu te laag, waardoor je zelfs zit te wachten bij een redirect van http:// naar https://.

Bovendien draait de site op een server met 100+ andere sites, dus kun je lokaal moeilijk de realistisch load testen.
Daarom is lokaal testen ook een verstandige zet om te doen, eventueel zou je dan ook kunnen testen bij andere hostingbedrijven. Met VPS'en bieden veel bedrijven een proefperiode aan die lang genoeg is om het een en ander uit te proberen. Zo ben ik er vaak genoeg achtergekomen dat de hosting het probleem was en niet de software. Al kunnen problemen in de software natuurlijk wel meer naar voren komen op trage servers.

Hilda zegt zelf dat het volgens haar webbureau draait op een vps, dus mochten er nog 100+ andere sites naast draaien, dan is het eventueel verstandig om eens met ze om tafel te gaan zitten. Al hoeft 100+ sites niet direct problemen te geven, dat hangt er ook vanaf hoeveel bezoekers er zijn natuurlijk. Al kan een vps op een drukke fysieke host al aardig traag worden bij weinig bezoekers.
 
Dierenspeciaalzaak
Berichten: 689
Lid geworden op: 20 juni 2012
Locatie: Emmeloord
Contacteer:

Re: Snelheid (of liever gezegd traagheid) webshop Opencart

05 juni 2015

Zit ik met alles fout? Meen je dat nou serieus?

Voordat je zoiets stellig poneert, kun je allicht de beleefdheid opbrengen even naar het datamodel van OpenCart te kijken. Dat spreekt namelijk boekdelen:

https://github.com/opencart/opencart/bl ... encart.sql

Ik had het natuurlijk over wat je zij met betrekking tot mijn gedeelte. Wat betrekking tot verhaal van TS gaf ik je juist gelijk.
Online Dierenspeciaalzaak is het adres voor uw huisdier.
Ohw en... Online Dierenspeciaalzaak BLOG!
 
Dierenspeciaalzaak
Berichten: 689
Lid geworden op: 20 juni 2012
Locatie: Emmeloord
Contacteer:

Re: Snelheid (of liever gezegd traagheid) webshop Opencart

05 juni 2015

Ook dan kan object buffering zorgen voor vertraging. Tussen ob_start() en ob_end_clean() hoeft maar ergens een trage functie te zitten en het gaat gewoon fout. Dat zou een SQL query kunnen zijn, inefficiënte lussen, ophalen van bestanden vanaf andere servers enzovoort.
Tussen ob_start() en ob_end_clean() doet OpenCart niets spannends:
ob_start();
require($file);
$output = ob_get_contents();
ob_end_clean();
Dat verdient niet de schoonheidsprijs, maar is wel een standaardtechniek om een string te gzippen. Winst is hier niet meer te behalen: de require van een template file heb je sowieso nodig.

Lokaal code en database tweaken is inderdaad verstandig. Maar netwerklatentie bij de provider los je er niet mee op. De TTFB is nu te laag, waardoor je zelfs zit te wachten bij een redirect van http:// naar https://.

Bovendien draait de site op een server met 100+ andere sites, dus kun je lokaal moeilijk de realistisch load testen.

Dan kun je nog beter vannacht om 3:00 uur de wekker zetten en kijken of de site nog steeds sloom is. Zo nee, dan weet je genoeg.

Dit probleem is vooral lastig omdat het niet slechts één probleem is. Hoge TTFB, geen client caching, slow queries en een complex template voor de render engine.
Kom ik terug op het eerdere punt. Als je compressie gebruikt, is TTFB pas wanneer de code volledig uitgevoerd is. Dat is wat het rare beeld geeft. Als je geen compressie zou gebruiken, zou de website gewoon heel traag laden, maar de TTFB vele malen gunstiger zijn.

Dat TTFB bij redirect hoog is, vind ik helemaal raar. Als je de redirect vanuit .htaccess regelt, zou dit nooit hoog moeten kunnen zijn? Zelfs met een vrijwel overbelaste server is dat dan zo'n mini proces, dat het nog een fractie van een seconde duurt.

Als ik dit goed begrijp, lijkt het er dan op, dat de redirect ook pas gegeven wordt nadat het hele document gerenderd is? Als ik redirect vanuit PHP doe om wat voor reden dan ook, staat deze bovenaan in source code met meteen er achter een exit(0);

Daarbij zal de website inderdaad natuurlijk lokaal anders presteren. Echter kun je wel redelijk zien welke processen het meeste tijd kosten met wat ik aangaf en daar dan kijken wat er eventueel fout gaat. Uiteraard wel ook volledige database een dump van maken voor lokaal.

Een alternatief zou zijn, die echo regels iets bij zetten in de zin van
if($_SERVER['REMOTE_ADDR'] == 'ipadres')

met het lokale IP adres van de ontwikkelaar. Dan kun je het wel op de live website zetten. Is natuurlijk ook beetje bah manier van debuggen, maar wel effectief.

Dan kun je ook goed achterhalen welke queries relatief lang duren en daar dan controleren of in de DB de juiste indexen voor aanwezig zijn.

Ik draai mijn eigen website ook op een shared hosting die vrij zwaar belast wordt op dit moment. Echter is bij mij als je door de website bladert de laad snelheid ook onder de 1s. Dus als je website echt optimaal geprogrammeerd is, zou je volgens mij nooit laad tijden van 5s of zelfs langer moeten hebben.
Online Dierenspeciaalzaak is het adres voor uw huisdier.
Ohw en... Online Dierenspeciaalzaak BLOG!
 
Gebruikersavatar
Ward
Berichten: 5343
Lid geworden op: 18 december 2010
Locatie: Eindhoven
Contacteer:

Re: Snelheid (of liever gezegd traagheid) webshop Opencart

05 juni 2015

Voor het profilen van PHP kun je bijvoorbeeld APD (Advanced PHP Debugger) gebruiken. Voorbeeld van de trace vind je op Stack Overflow:

http://stackoverflow.com/questions/2113 ... php-script

Hilda, kun je even in .htaccess kijken? Mag ook per PB of mail.
Dan kunnen we controleren hoe die redirect staat ingesteld.

Google klaagt overigens ook over die reactiesnelheid:

https://developers.google.com/speed/pag ... tage.nl%2F

Die compressie blijft een vakinhoudelijk discussiepunt. Enerzijds heb je een snellere respons als je alvast wat flusht terwijl de rest van de pagina nog in de maak is. Anderzijds moet je daarna ook veel meer bytes verstouwen. Voor de architectuur van OpenCart geldt dat de meeste webwinkels sneller worden mét compressie. Hilda heeft dat ondertussen ook bevestigd. OpenCart kan helaas niet alvast wat headers verzenden bijvoorbeeld.

Verder is deze nog interessant. Geeft mooi aan welk netwerk traag is:

http://tools.pingdom.com/ping/?target=l ... save=false
 
jessewillem
Berichten: 4
Lid geworden op: 16 juni 2014
Locatie: Koudum

Re: Snelheid (of liever gezegd traagheid) webshop Opencart

10 maart 2016

Ik kom toch nog even terug op deze.


Inmiddels is het probleem van de traagheid opgelost, na aanpassingen en een verhuizing van shared hosting naar vps. De grootste veroorzaker was een plugin met een klassiek OpenCart probleem: alle categorieen ophalen plus de producten die erbij horen. Dit zorgde voor 2300 queries per page load, waardoor het logisch is dat het traag wordt. 
 
puurhost
Berichten: 187
Lid geworden op: 05 april 2016
Contacteer:

Re: Snelheid (of liever gezegd traagheid) webshop Opencart

05 april 2016

Ik kom toch nog even terug op deze.


Inmiddels is het probleem van de traagheid opgelost, na aanpassingen en een verhuizing van shared hosting naar vps. De grootste veroorzaker was een plugin met een klassiek OpenCart probleem: alle categorieen ophalen plus de producten die erbij horen. Dit zorgde voor 2300 queries per page load, waardoor het logisch is dat het traag wordt. 
Heb je op de VPS wel een caching oplossing draaien? Anders is het een kwestie van tijd voor je het probleem gewoon weer gaat krijgen! 
Opzoek naar een webhoster die echt met je meedenkt?
Magento Webhosting, WooCommerce en nog veel meer systemen!
  • Vergelijkbare Onderwerpen
    Reacties
    Weergaves
    Laatste bericht