Jump to content
xt:Commerce Community Forum
426kg

Performance probleme mit guter Hardware

Recommended Posts

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

 

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...