Websitegeschwindigkeit Langsam

freekiller

Neu angemeldet
Registriert
17 Nov. 2015
Beiträge
43
Ort
Schweiz
Hallo zusammen,

ich habe ein VPS Hosting. Die Grundgeschwindigkeit ist mehr als befriedigend.

Nun habe ich einen Opencart OShop und merke, dass die Geschwindigkeit resp. die Ladezeit des Shops zunimmt sobald ich eine Grössere Anzahl an Produkten im Shop habe. Ich vermute es liegt an der SQL Datenbank, denn diese Umfasst schnell mal mehrere Hundert MB. Wenn ich mit meiner Vermutung richtig liege, wie kann ich es optimieren?

Bilder etc. sind komprimiert und werden schnell aufgerufen und externen Content ist praktisch nicht vorhanden, welches die Ladezeit erhöhen könnte.

Beste Dank für Tipps
 
Keiner wird dir helfen können, denn niemand kennt deinen Server und niemand weiss welches Shopsystem du verwendest.

Ich mag mal vermuten dass eine Datenbank mit mehreren hundert MB (in welcher anscheinend die Bilder auch noch abgelegt sind) mehr als ungeignet für deinen VPS sind.
Davon abgesehen lässt sich ja während des Shopaufrufs die Auslastung prima in einer Konsole ablesen.
 
Zuletzt bearbeitet:
Konfiguration des Datenbank-Servers wie Memory-Zuteilung, Datenbanktyp usw.
Konfiguration des Webserver, wie ist php angebunden, auch hier Speicherlimits,
Eigenschaften des Servers
Sonstige Dienste die im System laufen
Allgemeine Speicherauslastung
Allgemeine IO-Auslastung
Allgemeine Prozessor-Last / Load-Werte

Auch ist die Gesamtgröße der Datenbank nicht zwingend ausschlaggeben sondern vor allem die größe des zu selektierenden Bereichs und die komplexität der SQL-Abrage welche man im Normalfall im Debug-Modus ebenfalls erfährt.

Alles zusammen gebe ich Eraser schon recht - vieeeeel zu wenig Hintergrundinfos.
 
Das Problem scheint laut an der Anzeige der Gesamtmenge der Produkte und zusätzlich an der Zahl von Produkten in einer Warengruppe zu liegen.

Hab die Quelle nur überflogen.
 
Bin mir recht sicher dass die in Opencart bereits angelegt wurden.
 
Würd mir mal anschauen ob es irgendwelche brauchbaren gibt. Anscheinend kann man .

Wenn du nicht auf Opencart angewiesen bist, kann ich schwerstens empfehlen. Wir haben hier Shops mit hunderten Artikeln und kein Problem mit Ladezeiten.
 
@electric.larry:
Die Extension ist veraltet. Opencart hat einen Config-Eintrag "cache_type" (default: 'file') der APCu ('apc') und Memcache ('mem') unterstützt. Beide müsste man natürlich installieren, aber das Caching im Filesystem wird hier kaum das Bottleneck sein.
Sofern PHP < 5.5 genutzt wird wäre ein ByteCode Cache allerdings interessant (neuere PHP Versionen haben den ja dabei).. Wobei auch das nicht das Bottleneck ist...

@KaPiTN:
Mit Indizes ist der Software auch nicht mehr zu helfen...
https://github.com/opencart/opencart/blob/master/upload/system/library/cart/cart.php schrieb:
[src=php]
foreach ($cart_query->rows as $cart) {

[...]

foreach (json_decode($cart['option']) as $product_option_id => $value) {
$option_query = $this->db->query("SELECT po.product_option_id, po.option_id, od.name, o.type FROM " . DB_PREFIX . "product_option po LEFT JOIN `" . DB_PREFIX . "option` o ON (po.option_id = o.option_id) LEFT JOIN " . DB_PREFIX . "option_description od ON (o.option_id = od.option_id) WHERE po.product_option_id = '" . (int)$product_option_id . "' AND po.product_id = '" . (int)$cart['product_id'] . "' AND od.language_id = '" . (int)$this->config->get('config_language_id') . "'");

[...]

} elseif ($option_query->row['type'] == 'checkbox' && is_array($value)) {
foreach ($value as $product_option_value_id) {
$option_value_query = $this->db->query("SELECT ...
[/src]

https://github.com/opencart/opencart/blob/master/upload/php.ini schrieb:
[src=ini]max_execution_time = 36000;[/src]
hahahaha :D
 
Zuletzt bearbeitet:
LEFT JOIN? sowas nutzt man in production? Hab ich das letzte mal in ner SQL-Vorlesung vor 4 Jahren gesehen...

EDIT: meine natürlich nicht, dass man das nicht nutzen soll, aber vielleicht nicht mehrfach in einer user-triggered query.
 
Zuletzt bearbeitet:
Was ist denn das Problem an LEFT JOIN? Bzw. was sollte man stattdessen nutzen?

Magento benutzt Indextabellen, wo alles in einer Tabelle steht. (Alle Informationen zu diesem einen Produkt, was es so gibt, mit allen Attributen etc. pp)
Davor sind die Daten über mehrere Tabellen verteilt und müssten gejoint werden.
Ob das der Oberhammer ist, weiß ich aus Datenbanksicht jedoch nicht.
 
ist in den abfragen auf jeden Fall schneller, z.B. bei der angesprochenen Gesamtmenge der Artikel. Im Stackoverflow-Artikel sind weitere Probleme mit den Datenbankabfragen genannt.

Würde sagen, wir warten erst mal auf den TS und mehr Informationen.
 
  • Thread Starter Thread Starter
  • #13
Konfiguration des Datenbank-Servers wie Memory-Zuteilung, Datenbanktyp usw.
Konfiguration des Webserver, wie ist php angebunden, auch hier Speicherlimits,
Eigenschaften des Servers
Sonstige Dienste die im System laufen
Allgemeine Speicherauslastung
Allgemeine IO-Auslastung
Allgemeine Prozessor-Last / Load-Werte

Auch ist die Gesamtgröße der Datenbank nicht zwingend ausschlaggeben sondern vor allem die größe des zu selektierenden Bereichs und die komplexität der SQL-Abrage welche man im Normalfall im Debug-Modus ebenfalls erfährt.

Alles zusammen gebe ich Eraser schon recht - vieeeeel zu wenig Hintergrundinfos.

Eigenschaften des VP Servers:
Ubuntu 14.04 LTS
vCPU 1
Ram 2 GB
HDD 50GB

Installiertes Verwaltungssystem: Webuzo
Anwendungen welche für diverse Websites installiert sind:
PHP 5.4
Apache
CURL
MCrypt
MySQL
PERL
OpenLDAP
Python 2
Pure-FTPd
SQLite
BIND
Exim
Dovecot
LAMP Stack
PHP 5.5
CSF
Brute Force Detection
Linux Malware Detect
PHP 5.6

Aktuelle Auslastung:
2016-02-26 22_04_33-Eisnae - Powered by Webuzo.png


Gemäss einigen Hilfreichen Postings liegt es vermutlich tatsächlich an Opencart und deren Strucktur wie diese geladen werden resp. am Caching. Es gibt diverse Extensions welche verpsrechen die Zugriffsgeschwindigkeit zu erhöhen. Bsp.
 
@freekiller: Geld auf das Problem zu werfen wird dir in der Dimension leider nicht viel bringen.
Das Problem liegt tief in der Struktur von OpenCart. Ich habe ein Beispiel gegeben, in dem das super offensichtlich ist, aber es gibt davon natürlich noch mehr.
https://github.com/opencart/opencart/blob/master/upload/catalog/model/catalog/product.php schrieb:
[src=php] public function getProducts($data = array()) {

[...]

foreach ($query->rows as $result) {
$product_data[$result['product_id']] = $this->getProduct($result['product_id']);
}
[/src]
[src=php]
public function getProduct($product_id) {
$query = $this->db->query("SELECT DISTINCT *, pd.name AS name, p.image, m.name AS manufacturer, (SELECT price FROM " . DB_PREFIX . "product_discount pd2 WHERE pd2.product_id = p.product_id AND pd2.customer_group_id = '" . (int)$this->config->get('config_customer_group_id') . "' AND pd2.quantity = '1' AND ((pd2.date_start = '0000-00-00' OR pd2.date_start < NOW()) AND (pd2.date_end = '0000-00-00' OR pd2.date_end > NOW())) ORDER BY pd2.priority ASC, pd2.price ASC LIMIT 1) AS discount, (SELECT price FROM " . DB_PREFIX . "product_special ps WHERE ps.product_id = p.product_id AND ps.customer_group_id = '" . (int)$this->config->get('config_customer_group_id') . "' AND ((ps.date_start = '0000-00-00' OR ps.date_start < NOW()) AND (ps.date_end = '0000-00-00' OR ps.date_end > NOW())) ORDER BY ps.priority ASC, ps.price ASC LIMIT 1) AS special, (SELECT points FROM " . DB_PREFIX . "product_reward pr WHERE pr.product_id = p.product_id AND customer_group_id = '" . (int)$this->config->get('config_customer_group_id') . "') AS reward, (SELECT ss.name FROM " . DB_PREFIX . "stock_status ss WHERE ss.stock_status_id = p.stock_status_id AND ss.language_id = '" . (int)$this->config->get('config_language_id') . "') AS stock_status, (SELECT wcd.unit FROM " . DB_PREFIX . "weight_class_description wcd WHERE p.weight_class_id = wcd.weight_class_id AND wcd.language_id = '" . (int)$this->config->get('config_language_id') . "') AS weight_class, (SELECT lcd.unit FROM " . DB_PREFIX . "length_class_description lcd WHERE p.length_class_id = lcd.length_class_id AND lcd.language_id = '" . (int)$this->config->get('config_language_id') . "') AS length_class, (SELECT AVG(rating) AS total FROM " . DB_PREFIX . "review r1 WHERE r1.product_id = p.product_id AND r1.status = '1' GROUP BY r1.product_id) AS rating, (SELECT COUNT(*) AS total FROM " . DB_PREFIX . "review r2 WHERE r2.product_id = p.product_id AND r2.status = '1' GROUP BY r2.product_id) AS reviews, p.sort_order FROM " . DB_PREFIX . "product p LEFT JOIN " . DB_PREFIX . "product_description pd ON (p.product_id = pd.product_id) LEFT JOIN " . DB_PREFIX . "product_to_store p2s ON (p.product_id = p2s.product_id) LEFT JOIN " . DB_PREFIX . "manufacturer m ON (p.manufacturer_id = m.manufacturer_id) WHERE p.product_id = '" . (int)$product_id . "' AND pd.language_id = '" . (int)$this->config->get('config_language_id') . "' AND p.status = '1' AND p.date_available <= NOW() AND p2s.store_id = '" . (int)$this->config->get('config_store_id') . "'");
[/src]

Gleiches Anti-Pattern: SQL-Query in einer foreach. Dem Hersteller geht Performance schlicht am Allerwertesten vorbei. Da kratzt Caching dann auch nur noch an der Spitze des Eisbergs.

Wenn du viel Geld drauf wirfst, dann findest du vielleicht jemanden, der die schlimmsten Teile des Codes neu schreibt.
Ernsthaft: eine Suche (getProducts bekommt Filtereinstellungen als Parameter) in der die Zahl der ausgeführten SQL-Queries linear mit der Anzahl der Suchergebnisse wächst... Mit dem Code kann man höchstens Webmaster-Subforen in irgendwelchen obskuren Boards belustigen :D

Wenn möglich sofort wegwerfen und neu anfangen!
Wichtige Lektüre bevor Extensions gekauft oder Entwickler beschäftigt werden : Sunk Cost Fallacy
 
Mit dem Code kann man höchstens Webmaster-Subforen in irgendwelchen obskuren Boards belustigen :D
Also uns? :D

Könnte günstiger sein, auf Magento umzusteigen. PrestaShop ist meiner Erfahrung nach auch nicht das schlechteste Programm, habe mir mangels Bedarf aber deren Queries noch nicht angeschaut...
 
@TS nu die Hardware sollte bei vernünftiger Software wohl reichen - das hier die Software das Problem ist haben andere ja geschrieben ^^
 
Zurück
Oben