Gesucht: xtc_db_close()!

[timopaul]

Guten Tag,

wir arbeiten hier gerade an einem mittelgroßen Shop. Circa 35.000 Artikel in zwei Sprachen, 25 Kundengruppen mit separaten Preisen (keine Staffelpreise) für fast jeden Artikel. Der Shop ist mittlerweile auf einen managed Cloud-Server umgezogen. Nun rufen die Shop-Kunden den Shop-Betreiber an und teilen mit, dass sie leider nichts bestellen können da die Seiten zu lange laden (teilweise bis zu 14 Sekunden). Über Umwege landet diese Anfrage dann bei mir. Im Rechenzentrum sagt man mir, die Datenbank sei ausge-/überlastet. Woraufhin wir einige Abfragen optimiert haben und weitere Indizes hinzugefügt. Zum teil wurden die Abfragen auch schneller und es schien sich beruhigt zu haben. Heute allerdings stand der Server/Shop wieder still und im Rechenzentrum wurden manuell offene Datenbankabfragen gekillt (wurde mir berichtet) um wieder etwas Luft zu machen. Nun aber zum eigentlichen Thema:

Wir haben gesucht und gesucht aber nichts gefunden. Wo wird die Datenbankverbindung wieder geschlossen? Rein Theoretisch sollte dies doch in der /includes/application_bottom.php geschehen? Warum geschieht das dort nicht? Wo werden die geschlossen? Werden die überhaupt geschlossen? Warum werden die nicht geschlossen? Wer kann mir darauf eine oder mehrere Antworten liefern?

Besten Gruß,
Timo

Linkback: https://www.modified-shop.org/forum/index.php?topic=32101.0

[hpzeller]

Hallo Timo

[...]
Wir haben gesucht und gesucht aber nichts gefunden. Wo wird die Datenbankverbindung wieder geschlossen? Rein Theoretisch sollte dies doch in der /includes/application_bottom.php geschehen?
[...]

Die Datenbankverbindung wird automatisch geschlossen nach der Skriptausführung.
Siehe hier -> http://php.net/manual/de/function.session-write-close.php

PS:
Tipp: Schau mal in der 'cofigure.php' ob "define('USE_PCONNECT', 'false');" auch wirklich auf 'false' steht, denn das kann zu Problemen führen.

Ausserdem könntest Du in der 'session.php' folgenden Code

Code: PHP  [Auswählen]

  function xtc_session_start() {
    return session_start();
  }

durch diesen Code ersetzen

Code: PHP  [Auswählen]

  function xtc_session_start() {
    register_shutdown_function('session_write_close');
    return session_start();
  }

Damit wird sichergestellt das die Session am Ende geschlossen wird.

Gruss
Hanspeter

[webald]

was spricht dagegen, dass Ihr das genau in der application_bottom.php ergänzt?

application_bottom.php im Admin -Verzeichnis nicht vergessen.

[webald]

Circa 35.000 Artikel in zwei Sprachen, 25 Kundengruppen mit separaten Preisen (keine Staffelpreise) für fast jeden Artikel.

Nur so aus Neugier: Wieviele Kategorien und wie hoch ist die Kategorietiefe?

[hpzeller]

Hallo Timo

Sorry, in meiner 'Antwort #1' ist mir ein Fehler unterlaufen, der Link ist falsch, aber die Datenbankverbindung wird nach ausführen des Skripts automatisch geschlossen wenn die Verbindung nicht persistent ist, also nicht mit 'mysql_pconnect' geöffnet wurde.
Siehe hier -> http://php.net/manual/de/function.mysql-close.php

Gruss
Hanspeter

[timopaul]

Servus Hanspeter,

[...]

[...]
Wir haben gesucht und gesucht aber nichts gefunden. Wo wird die Datenbankverbindung wieder geschlossen? Rein Theoretisch sollte dies doch in der /includes/application_bottom.php geschehen?
[...]

Die Datenbankverbindung wird automatisch geschlossen nach der Skriptausführung.
Siehe hier -> http://php.net/manual/de/function.mysql-close.php

Der gute alte Garbage Collector, wie konnte ich den nur vergessen. Da habe ich ja viel Wind um nichts gemacht.

PS:
Tipp: Schau mal in der 'cofigure.php' ob "define('USE_PCONNECT', 'false');" auch wirklich auf 'false' steht, denn das kann zu Problemen führen.
[...]

Ja, das steht auf 'false', so wie es sein sollte. Stellt sich mir immer noch die Frage was die Datenbank für ein Problem hat. Die paar Tausend Datensätze sollten doch zu handhaben sein ?!

Circa 35.000 Artikel in zwei Sprachen, 25 Kundengruppen mit separaten Preisen (keine Staffelpreise) für fast jeden Artikel.

Nur so aus Neugier: Wieviele Kategorien und wie hoch ist die Kategorietiefe?

257 Kategorien, auch zwei Sprachen, alle auf der ersten Ebene. Frag bitte nicht genauer nach dem Hintergrund, das ist sehr komplex und soll so sein.

Besten Gruß,
Timo

[Modulfux]

Schalte testweise mal die Shopstat-Url aus. Denn die ist bei Shops mit vielen Kategorien und Produkten der wahre Performancekiller. Wenn der Shop dann noch gleichzeitig gut besucht ist, dann macht insbesondere der SQL-Server schon mal dicke Backen.

Gruß
Ronny

[timopaul]

Aloha Ronny,

auch ein guter Tipp, danke. Doch die sind gar nicht an.

Bevor weitere Rückfragen dazu kommen: Der Shop nur für ausgewählte Großkunden zugänglich, daher ist uns Google egal.

Besten Gruß,
Timo

[Marcus Kreusch]

Hey Timo,

hast du schon überprüft, ob es bestimmte Querys gibt, die besonders langsam laufen und damit andere blockieren? Meist gibt es ein bis zwei Flaschenhälse, die sich so ganz gut finden lassen.

Viele Grüße
Marcus

[webald]

Nur so aus Neugier: Wieviele Kategorien und wie hoch ist die Kategorietiefe?

257 Kategorien, auch zwei Sprachen, alle auf der ersten Ebene. Frag bitte nicht genauer nach dem Hintergrund, das ist sehr komplex und soll so sein.

Ich hatte schlimmeres erwartet, etwa eine Kategorietiefe von 8, als 8 Sub- und SubSub-Kategorien.

Ich hatte mir mal einen Shop aufgesetzt um zu testen wie lange ein Import dauert und haben dem Shop 350.000 Artikel zum fressen vorgeworfen. Wenn ich den aufrufe, dann braucht der auf einer Windows-Xampp-Test-Installation etwa 4-5 Sekunden mit Standardeinstellungen, ohne Eingriffe in DB und Index.

Ich schaffe es aberauf fast 10 Sekunden, wenn ich die Artikelanzahl hinter den Kategorien anzeigen lasse.

Bei 14 Sekunden wird da doch noch was anderes geladen. Externe Daten?

Was den Ausgang angeht "db_close" sagt meine Erfahrung aus .NET: traue dem Garbage-Collector nicht. Der kommt irgendwann, aber nicht zwingend sofort nach dem Senden der Antwort. Daher ist explizit zu machen bestimmt ein erster Schritt.

[timopaul]

Guten Tag Genossen,

hast du schon überprüft, ob es bestimmte Querys gibt, die besonders langsam laufen und damit andere blockieren? Meist gibt es ein bis zwei Flaschenhälse, die sich so ganz gut finden lassen.

Ja, leider ohne Erfolg. Wir können nichts explizites als Ursache erkennen. Einziger Anhaltspunkt den wir aktuell haben, ist dass sobald von den Jungs im Rechenzentrum der MySQL-Dienst neu gestartet wurde beziehungsweise manuell die offenen Anfragen gekillt werden alles vergleichsweise flott läuft. Woraufhin die Vermutung das der nicht vorhandene db_close schuld ist entstand.

[...]
Ich schaffe es aberauf fast 10 Sekunden, wenn ich die Artikelanzahl hinter den Kategorien anzeigen lasse.

Guter Hinweis, die wurden angezeigt. Hat leider nicht den gewünschten WOW-Effekt gebracht.

Bei 14 Sekunden wird da doch noch was anderes geladen. Externe Daten?

Nein, nichts externes für die Shop-Seiten. Ein weiterer Dienst füttert im Hintergrund die Datenbank regelmäßig mit neuen Daten, den haben wir auch schon optimiert.

Zu den 14 Sekunden muss ich auch sagen, dass dies nur die Startseite betraf, wo alle Neuheiten (bis zu 1.000 Artikel) angezeigt wurden. Einzelne Kategorie- und Detailseiten mit weniger Artikeln waren schneller, doch teilweise auch bis zu 4 Sekunden, was deutlich zu lange ist.

Wobei diese aktuell im Schnitt bei 2 Sekunden liegen, nachdem gestern Abend im Rechenzentrum der MySQL-Dienst neu gestartet wurde. Was wiederum unseren Verdacht bestätigt.

Was den Ausgang angeht "db_close" sagt meine Erfahrung aus .NET: traue dem Garbage-Collector nicht. Der kommt irgendwann, aber nicht zwingend sofort nach dem Senden der Antwort. Daher ist explizit zu machen bestimmt ein erster Schritt.

Also doch noch so wie damals in meinen JAVA Zeiten: "Vertraue niemals dem Garbage Collector sondern recycle alles selbst", wurde mir damals gelehrt. Hatte es schon vermutet und wurde durch weitere Recherchen bestätigt.

Woraufhin ich jetzt nicht nur die bekannteste Resource $db_link am Ende schließe, sondern mir alle anschauen und die vom Typ "mysql link" und "mysql result" am Scriptende frei gebe. Folgendes habe ich in der /includes/application_bottom.php danz am Ende dazu gebastelt und sehe bisher das alles rund läuft. Bin natürlich wie immer dankbar wenn ein zweites, drittes oder noch mehr Paar Augen darauf geworfen wird um eventuelle Schwachstellen zu erkennen:

Code: PHP  [Auswählen]

// BOF - Timo Paul (mail[at]timopaul[dot]biz) - 2015-01-28 - close all resources
function close_resources($vars) {
  foreach ($vars as $k => $v) {
    global $$k;
    if (is_resource($$k)) {
      switch (get_resource_type($$k)) {
        case 'mysql link':
          mysql_close($$k);
          break;
        case 'mysql result':
          mysql_free_result($$k);
          break;
      }
    }
  }
}
register_shutdown_function('close_resources', get_defined_vars());
// EOF - Timo Paul (mail[at]timopaul[dot]biz) - 2015-01-28 - close all resources

Sobald ich neue Erkenntnisse habe ob dies eine sinnvolle Lösung war/ist werde ich mich spätestens wieder melden.

Frohes Schaffen,
Timo

[webald]

Mir fallen da 2 Sachen ins Auge:

Ein weiterer Dienst füttert im Hintergrund die Datenbank regelmäßig mit neuen Daten, den haben wir auch schon optimiert.

und

Zu den 14 Sekunden muss ich auch sagen, dass dies nur die Startseite betraf, wo alle Neuheiten (bis zu 1.000 Artikel) angezeigt wurden. Einzelne Kategorie- und Detailseiten mit weniger Artikeln waren schneller, doch teilweise auch bis zu 4 Sekunden, was deutlich zu lange ist.

1. Bist Du sicher, dass der Hintergrund-Dienst nicht die offenen DB-Verbindungen erzeugt? Führt der u. U. zu Datensatzsperren, welche sich natürlich auf den Shop auswirken?

2. Nur neue Artikel? Wie werden die rausgesucht? Fehlt da am Ende ein Index?

[Marcus Kreusch]

Wir können nichts explizites als Ursache erkennen. Einziger Anhaltspunkt den wir aktuell haben, ist dass sobald von den Jungs im Rechenzentrum der MySQL-Dienst neu gestartet wurde beziehungsweise manuell die offenen Anfragen gekillt werden alles vergleichsweise flott läuft.

Heißt das, dass alle eure Querys in unter 0.05s durchgehen?
Alles darüber sollte die Ausnahme sein, z.B. die Suche.

[Modulfux]

Was auch noch eine Möglichkeit wäre, gerade wenn auf der Startseite schon 1000 Produkte angezeigt werden, das Query umzubauen. Statt über eine while-Schleife immer wieder die einzelnen products_id abzufragen, die WHERE-Klausel mit products_id IN () zu beschelunigen.

Gruß
Ronny

[webald]

Je länger ich darüber nachdenke, glaube ich dass das nicht mal unbedingt an Abfragen, Indizes oder Shop liegt, sonder eher an der Config von Apache und mysql.

Was ist immer gleich, wenn die Zugriffe langsam werden? Es gibt offene Verbindungen. Sobald die aber gekillt werden ist es wieder flott. Was ich mir vorstellen könnte, ist das im Hintergrund die max. Anzahl an Verbindungen erreicht ist und der Server wartet bis der Garbage-Collector sich bequemt mal wieder eine Verbindung zu schließen. Manchmal hatl nicht rechtzeitig und es timeouted.

Wenn ich das richtig im Kopf habe, dann gibt es Verbindungslimits für mysql, httpd und max open files. wenn eine davon zu niedrig ist, dann blockt das den Rest. Aber für sowas gibt es ja Profi-Apachen.