Performance Probleme aufgrund der Funktion oxArticle::getStockCheckQuery()

In manchen Situation erhält mal beim Shopsystem OXID unerwartet einen Server Error 500 (Timeout), ohne das es irgendwelche signifikanten Änderungen an der Shopsoftware oder der Infrastruktur gemacht worden sind. I.d.R. ist der erste Schritt zur Fehlerbehebung ein Neustart des Servers und oft erhält man von seinem Hoster auch die Rückmeldung, dass der Server unter sehr hoher Last stand. Oft hilft dieser Lösungsansatz, aber was wenn dieser Fehler plötzlich laufend und in der Hochsaison auftritt? Kann es sein, dass Ihr OXID Shop unter dem Bug 0002423 (oxArticle::getStockCheckQuery()) leidet!? Wir zeigen Ihnen die Lösung.

Nach langer Suche und dem Einsatz von Tideways konnten wir die problematische Funktion lokalisieren und sind auch schnell auf den OXID Bug 0002423(oxArticle::getStockCheckQuery()) gestoßen.
Auf Nachfrage beim offiziellen OXID Support haben wir dann folgende Antwort bekommen:

Sehr geehrter Herr Kussin,

vielen Dank für Ihre Rückmeldung.

Dieser Bug wurde bereits berichtet in unserem öffentlichen Bugtracker unter https://bugs.oxid-esales.com/view.php?id=2423 und von unseren Entwicklern auf die Version 6.0.0 postponed.

Eine schnelle Lösung kann hier nicht angeboten werden, da dies nur durch DB-Änderungen behoben werden kann und somit nicht in ein Patch, sondern nur in einem nächsten UPDATE bereitgestellt werden kann.

Mit freundlichen Grüßen
Technical Support

An dieser stelle möchte ich anmerken, dass der Bug 0002423 am 20.01.2011 gemeldet wurde und wir am 24.01.2017 die Version OXID PE 4.10.1 eingesetzt hatten, d.h. wir erwarten einen Bugfix ca. 2020.

Falls Sie das Problem früher lösen wollen, dann kommentieren Sie in der folgenden Funktion einfach die Codezeilen zwischen der ersten if-Funktion aus:

/**
 * Returns part of sql query used in active snippet. If config
 * option "blUseStock" is TRUE checks if "oxstockflag != 2 or
 * ( oxstock + oxvarstock ) > 0". If config option "blVariantParentBuyable" 
 * is TRUE checks if product has variants, and if has - checks is
 * there at least one variant which is buyable. If config option
 * option "blUseTimeCheck" is TRUE additionally checks if variants
 * "oxactivefrom < current data < oxactiveto" 
 *
 * @param bool $blForceCoreTable force core table usage
 *
 * @return string
 */
public function getStockCheckQuery($blForceCoreTable = null)
{
    $myConfig = $this->getConfig();
    $sTable = $this->getViewName($blForceCoreTable);

    $sQ = "";

    //do not check for variants
    if ($myConfig->getConfigParam('blUseStock')) {
//        $sQ = " and ( $sTable.oxstockflag != 2 or ( $sTable.oxstock + $sTable.oxvarstock ) > 0  ) ";
//        //V #M513: When Parent article is not purchasable, it's visibility should be displayed in shop only if any of Variants is available.
//        if (!$myConfig->getConfigParam('blVariantParentBuyable')) {
//            $sTimeCheckQ = '';
//            if ($myConfig->getConfigParam('blUseTimeCheck')) {
//                $sDate = date('Y-m-d H:i:s', oxRegistry::get("oxUtilsDate")->getTime());
//                $sTimeCheckQ = " or ( art.oxactivefrom < '$sDate' and art.oxactiveto > '$sDate' )";
//            }
//            $sQ = " $sQ and IF( $sTable.oxvarcount = 0, 1, ( select 1 from $sTable as art where art.oxparentid=$sTable.oxid and ( art.oxactive = 1 $sTimeCheckQ ) and ( art.oxstockflag != 2 or art.oxstock > 0 ) limit 1 ) ) ";
//        }
    }

    return $sQ;
}

Als abschliessende Information zur Funktion oxArticle::getStockCheckQuery() und zum Fehler – die Funktion ist Teil der OXID Lagerverwaltung und wir im Falle des Auftreten des Fehlers i.d.R. nicht benötigt, denn die Performance Probleme treten erst bei sehr großen Produktsortimenten (über 10.000 Artikel) auf und in dem Fall wird normalerweise eine zusätzliche Software für die Lagerverwaltung eingesetzt, die die Aufgaben für OXID übernimmt.