Performance probleme mit guter Hardware

[426kg]

Guten Tag,

wir unterstützen unseren Kunden Mountainspirit OHG (shop.mountainspirit.it) wo ein xt-commerce 4.2 installiert ist.

Nun haben wir das Problem, dass die TTFB fasst 2 Sekunden beträgt, egal ob content Seite oder Artikel listing.

Wir haben bereits mysql optimierungen durchgefuehrt, APACHE mit NGIX verglichen aber nichts hat uns vorwärts gebracht.

 

Wir haben einen 8-core 2.3 Prozessor mit 32GB RAM SSD, da sollte man schon was rausholen können.

 

Ich freue mich auf jeden Tipp. Installierte Plugins sind: Master Slave, Produktoptionen, Konfigurierbare Artikel.

 

Danke

Daniel

 

[xt:Commerce]

artikel/kategorie anzahl ?

Bei 2 Sekunden stimmt definitiv etwas in der installation nicht vor allem bei content seiten, da sollte das schon bei einer nicht optimierten installation auf gutem hosting in bereich von 250-300 ms sein.

Schon mal mit newrelic oder tideways angesehen woran es in etwa hängt ?

[426kg]

Erstens vielen dank für das Feedback. Der shop hat 187 Kategorien und 19663 Artikel.

Ich werde mit Rewrelic oder Tideways testen und dann berichten.

Bzgl. Installation handelt sich es um eine standard 4.2 Installation mit allen Patches und genauergenommen sind folgende plugins installiert:

Google Sitemap,Import / Export,Options und Freitext Modul,Produkt Konfigurator,Cash on delivery (Nachnahme),Fuzzy Search,Clean Cache,Startpage Products,Specials Page,PDF-Rechnung (Orders invoices),SEPA Lastschrift,Prepayment (Vorkasse),PayPal + PayPal Express,Newsletter2Go E-Mail Marketing,Google Analytics,Master Slave,Slider Plugin for xt:Commerce 4 / VEYTON,Schnellbearbeitung,Gutscheine/Kupons,Canonical Tags,it:logistik Hersteller Filter for xt:Commerce 4,Reviews,it:logistik M/S Extension Plugin for xt:Commerce 4 / VEYTON,Wirecard Checkout Page

LG

[jwinkel]

15 hours ago, administrator said:

... Bei 2 Sekunden stimmt definitiv etwas in der installation nicht ...

Das kann ich so nicht bestätigen, wir haben ähnliche Probleme. Wir hatten bei unserem früheren Hoster ähnliche Probleme, die sich bis auf 8s Parse-Time für bestimmte Artikellisting-Seiten steigerten. Nach einem Umzug (es ist übrigens nicht mehr einfach, einen managed Server mit php 5.5 und mysql 5.5 zu mieten) sind wir nun bei 1,8s für die selbe Seite, was immer noch nicht wirklich befriedigend ist, aber nach Aussage des Hosters sind alle Möglichkeiten ausgeschöpft. Contentseiten etc. sind mit 200 bis 300ms wieder o.k., das waren dann auch mal 2-3s.

Soweit ich das derzeit beurteilen kann liegt es bei uns am Master-Slave Plugin, das bei vielen Master/Slave Artikeln sehr viel Leistung verbraucht.

Hoffentlich kommt ioncube bald mit dem decoder für php7...

[426kg]

Genau, php7 wird hier einiges nach vorne bringen. Wir messen gerade mit tideways und man sieht klar das es an Master Slave liegt.

[jwinkel]

Dann muss ja nur noch xt:C einsehen dass in dem Plugin der Wurm sitzt...

[Alex@4tfm]

Man munkelt, dass da was gemacht wird für die kommende Version...

[jwinkel]

Ich glaube das erst wenn ich es sehe - zuletzt hieß es vom Support dass M/S völlig in Ordnung sei und es keine Performance-Probleme gebe...

Aber die Hoffnung stirbt ja zuletzt

[Alex@4tfm]

Mag sein, aber schneller geht immer

[oldbear]

habe schon vor einiger Zeit herausgefunden:

das liegt am Zusammenspiel von xt_special_products und xt_master_slave ( Die Hooks für die Sortierung )

Es wird über die Standard-Klassen eine extrem unperformante Query erzeugt ( die CASE-Abfrage)

SELECT DISTINCT p.products_id , p.products_model AS model ,
CASE
WHEN p.products_master_flag=1
    THEN (SELECT DISTINCT MIN(ps.products_price)FROM xt_products ps WHERE ps.products_master_model=model)
WHEN pps.specials_price>0
    THEN pps.specials_price
ELSE p.products_price END AS sort_price FROM xt_products p INNER JOIN xt_products_to_categories p2c ON p2c.products_id = p.products_id and p2c.store_id='1' LEFT JOIN xt_categories c ON p2c.categories_id = c.categories_id LEFT JOIN xt_products_price_special pps ON p.products_id = pps.products_id and (pps.date_available <= '2016-02-28 17:40:43' or pps.date_available = 0) and (pps.date_expired >= '2016-02-28 17:40:43' or pps.date_expired = 0) and (pps.group_permission_1=1 or pps.group_permission_all=1) left JOIN xt_products_permission group_permission ON (group_permission.pid = p.products_id and group_permission.pgroup = 'group_permission_1' ) left JOIN xt_products_permission shop ON (shop.pid = p.products_id and shop.pgroup = 'shop_1' ) LEFT JOIN xt_seo_url su ON (p.products_id = su.link_id and su.link_type='1' and su.store_id='1') WHERE p.products_price > 0 and 3 in (c.categories_id, c.parent_id) and p2c.store_id='1' and group_permission.permission IS NULL and shop.permission IS NULL and p.products_status = '1' and su.language_code = 'de' and su.store_id='1' and (p.products_master_model > '')
ORDER BY sort_price

Netterweise macht Master/Slave das ( die ganzen pps-Abfragen ) auch, wenn die Sonderpreise deaktiviert sind

Grüsse

 

 

[426kg]

19 hours ago, oldbear said:

habe schon vor einiger Zeit herausgefunden:

das liegt am Zusammenspiel von xt_special_products und xt_master_slave ( Die Hooks für die Sortierung )

Es wird über die Standard-Klassen eine extrem unperformante Query erzeugt ( die CASE-Abfrage)

SELECT DISTINCT p.products_id , p.products_model AS model ,
CASE
WHEN p.products_master_flag=1
    THEN (SELECT DISTINCT MIN(ps.products_price)FROM xt_products ps WHERE ps.products_master_model=model)
WHEN pps.specials_price>0
    THEN pps.specials_price
ELSE p.products_price END AS sort_price FROM xt_products p INNER JOIN xt_products_to_categories p2c ON p2c.products_id = p.products_id and p2c.store_id='1' LEFT JOIN xt_categories c ON p2c.categories_id = c.categories_id LEFT JOIN xt_products_price_special pps ON p.products_id = pps.products_id and (pps.date_available <= '2016-02-28 17:40:43' or pps.date_available = 0) and (pps.date_expired >= '2016-02-28 17:40:43' or pps.date_expired = 0) and (pps.group_permission_1=1 or pps.group_permission_all=1) left JOIN xt_products_permission group_permission ON (group_permission.pid = p.products_id and group_permission.pgroup = 'group_permission_1' ) left JOIN xt_products_permission shop ON (shop.pid = p.products_id and shop.pgroup = 'shop_1' ) LEFT JOIN xt_seo_url su ON (p.products_id = su.link_id and su.link_type='1' and su.store_id='1') WHERE p.products_price > 0 and 3 in (c.categories_id, c.parent_id) and p2c.store_id='1' and group_permission.permission IS NULL and shop.permission IS NULL and p.products_status = '1' and su.language_code = 'de' and su.store_id='1' and (p.products_master_model > '')
ORDER BY sort_price

Netterweise macht Master/Slave das ( die ganzen pps-Abfragen ) auch, wenn die Sonderpreise deaktiviert sind

Grüsse

 

 

Hallo oldbear, Danke für dein interessanten Hinweis.

auch wenn man die Query umschreibt:

/*$this->setSQL_COLS(", CASE
                            WHEN p.products_master_flag=1 THEN (SELECT MIN(ps.products_price)FROM ".TABLE_PRODUCTS." ps WHERE ps.products_master_model=model)
                            WHEN pps.specials_price>0 THEN pps.specials_price
                            ELSE p.products_price
                        END AS sort_price ");*/
    wird zu
    $this->setSQL_COLS(", p.products_price AS sort_price ");

bringt es leider keinen Wandel an der responsetime.

 

Ich schätze es gibt andere schwere joins im Code.

 

[jwinkel]

Ich habe (ohne Messwerte) das "Gefühl", dass es nicht an den Queries liegt. Wir haben mal einige Tage das SQL-Log mitlaufen lassen, die Ergebnisse waren unauffällig.

[J_Kroeger]

gibt es schon eine Lösung, damit der Shop mit Master/Slave schneller läuft?

[426kg]

Hallo, wir haben mit Xt zusammen erkannt, das M/S zwar die Seite langsam macht, aber unser Problem war das Menue mit den genesteten Joins. Wir haben somit die seite auf 800ms gebracht, indem wir ein full page cache des Menues realisiert haben.