ImageProxyAction erstellt Datenbank Verbindungen für jede Anfrage

  • Betroffene Version
    WoltLab Suite 3.1
    Betroffene App
    WoltLab Suite Core

    Bei jeder Anfrage an /image-proxy wird eine neue Datenbank Verbindung erstellt und die Session/User queries ausgeführt.

    Dies kann bei einer großen Anzahl an Bildern auf einer Seite dazu führen, dass das Limit der maximalen Verbindungen erreicht wird und nicht benötigte Queries ausgeführt werden.

    Nachdem ImageProxyAction über das Dateisystem läuft und keine Datenbank benötigt sollte hier auch keine Verbindung erstellt werden.

    Foren
    WSC 5.xWSC 5.x WCF 4.x phpBB 3.x XenForo 1.x
    hayday-forum.detrueadventure.de/forum vw-page.com msx-125.de/forum mineyourmind.net/forum
    brawlstar.denc750.de/forum kadett-forum.de xv950r.de/forum
    clashroyaleforum.dehonda-crosstourer.de/forum dr-125.de/dr125-forum
    clashofclansforum.decb-1100.de/forum
    boombeachforum.dexsr900.de/forum
    mt09.de/forumswm-motorrad.com/forum
    mt10-forum.de
    • Offizieller Beitrag

    Hallo,

    und keine Datenbank benötigt

    das ist nicht korrekt. Die Optionen müssen bekannt sein und auch der Autoloader muss initialisiert werden.

    dass das Limit der maximalen Verbindungen erreicht wird

    Dann ist das System nicht korrekt konfiguriert und entweder das Limit an Datenbankverbindungen zu gering oder die maximale Anzahl an PHP-Workern zu hoch.

  • Tim Düsterhus 3. Mai 2021 um 09:32

    Hat das Label Ist kein Fehler hinzugefügt.
  • Welche Optionen müssen bekannt sein? Die sind doch in der options.inc.php cached.

    Wenn eine Seite z.B. 400 Image Proxy Bilder hat, werden hier 400 Datenbank Verbindungen aufgebaut. Ja, das Limit kann erhöht werden aber ist es wirklich nötig so viele Verbindungen aufzubauen?

    Es würde auch die Verarbeitungszeit um einiges verkürzen, wenn diese vorhanden sind und daher die Bilder früher anzeigen. Beispiel:

    ImageProxyAction

    Simples PHP Script

    Nginx: rewrite ^/core/image-proxy/ /test.php;

    Diese Spikes werden durch einen Besucher, auf einer Seite ausgelöst:

    Foren
    WSC 5.xWSC 5.x WCF 4.x phpBB 3.x XenForo 1.x
    hayday-forum.detrueadventure.de/forum vw-page.com msx-125.de/forum mineyourmind.net/forum
    brawlstar.denc750.de/forum kadett-forum.de xv950r.de/forum
    clashroyaleforum.dehonda-crosstourer.de/forum dr-125.de/dr125-forum
    clashofclansforum.decb-1100.de/forum
    boombeachforum.dexsr900.de/forum
    mt09.de/forumswm-motorrad.com/forum
    mt10-forum.de
    • Offizieller Beitrag

    Hallo,

    Welche Optionen müssen bekannt sein?

    Das Signing-Secret, dass du in deinem Beispielscript ignorierst.

    Wenn eine Seite z.B. 400 Image Proxy Bilder hat

    Ich bin davon ausgegangen, dass geprüft wird, ob das Bild bereits gecached vorliegt und in dem Fall lediglich die statische URL ausgegeben wird, das ist aktuell tatsächlich nicht der Fall. Ich notier das mal als Issue.

    werden hier 400 Datenbank Verbindungen aufgebaut. Ja, das Limit kann erhöht werden aber ist es wirklich nötig so viele Verbindungen aufzubauen?

    Wenn in dem Fall wirklich 400 Datenbank-Verbindungen aufgebaut werden, dann ist erfahrungsgemäß die Anzahl der PHP-Worker deutlich zu hoch konfiguriert. Bei der Menge an Workern roflstompen die sich alle gegenseitig den CPU-Cache. Unsere Software ist i.d.R. CPU-bound, nicht IO-bound.

  • Deinem Script fehlt mindestens noch die Speicherung der Dateien. Und WSC-konform würde das Laden des WSC und damit auch Datenbank-Verbindungen voraussetzen.

    Der Teil wird nicht ausgeführt, wenn die Datei bereits heruntergeladen wurde, daher ist es bei dem beschriebenen Problem nicht relevant.

    Ich bin davon ausgegangen, dass geprüft wird, ob das Bild bereits gecached vorliegt und in dem Fall lediglich die statische URL ausgegeben wird, das ist aktuell tatsächlich nicht der Fall. Ich notier das mal als Issue.

    Hier wird es überprüft: https://github.com/WoltLab/WCF/bl….class.php#L104

    Jedoch wird durch die Initialisierung des Cores eine Datenbank Verbindung aufgebaut.

    Danke.

    Wenn in dem Fall wirklich 400 Datenbank-Verbindungen aufgebaut werden, dann ist erfahrungsgemäß die Anzahl der PHP-Worker deutlich zu hoch konfiguriert. Bei der Menge an Workern roflstompen die sich alle gegenseitig den CPU-Cache. Unsere Software ist i.d.R. CPU-bound, nicht IO-bound.

    Wir hatten diese erhöht, weil es durch die vielen Anfragen an den Image Proxy zu bad gateways geführt hat, welches dann dazu geführt hat, dass das Datenbanklimit erreicht wurde, wo durch festgestellt wurde das für jede Anfrage auf ein bereits heruntergeladenes Bild eine Verbindung aufgebaut wird.

    Foren
    WSC 5.xWSC 5.x WCF 4.x phpBB 3.x XenForo 1.x
    hayday-forum.detrueadventure.de/forum vw-page.com msx-125.de/forum mineyourmind.net/forum
    brawlstar.denc750.de/forum kadett-forum.de xv950r.de/forum
    clashroyaleforum.dehonda-crosstourer.de/forum dr-125.de/dr125-forum
    clashofclansforum.decb-1100.de/forum
    boombeachforum.dexsr900.de/forum
    mt09.de/forumswm-motorrad.com/forum
    mt10-forum.de
    • Offizieller Beitrag

    Hallo,

    weil es durch die vielen Anfragen an den Image Proxy zu bad gateways geführt hat

    dann passt deine Queuing-Logik nicht oder die Timeouts sind extrem niedrig konfiguriert[1]. Faustregel für die maximale Anzahl an PHP-Workern ist die Anzahl der Hyperthreads × 2. Dann kann jeder Hyperthread einen aktiven PHP-Prozess haben und einen der auf IO wartet. Bei lokalem MySQL sollte das Limit eher noch kleiner sein.

    [1] Falls du Unix-Sockets benutzt, dann stell auf TCP via lo um.

  • Hm, welche genauen Einstellungen meinst du? Bezüglich Queuing-Logik und Timeouts?

    Foren
    WSC 5.xWSC 5.x WCF 4.x phpBB 3.x XenForo 1.x
    hayday-forum.detrueadventure.de/forum vw-page.com msx-125.de/forum mineyourmind.net/forum
    brawlstar.denc750.de/forum kadett-forum.de xv950r.de/forum
    clashroyaleforum.dehonda-crosstourer.de/forum dr-125.de/dr125-forum
    clashofclansforum.decb-1100.de/forum
    boombeachforum.dexsr900.de/forum
    mt09.de/forumswm-motorrad.com/forum
    mt10-forum.de
    • Offizieller Beitrag

    Hallo,

    Bezüglich Queuing-Logik und Timeouts?

    das hängt ganz von deinem genauen Set-Up ab. Ich kann hier auch nicht detaillierte Hilfestellung zur individuellen Serverkonfiguration geben. Ich hatte historisch aber die Erfahrung gemacht, dass das Queuing mit TCP-Sockets deutlich besser skaliert als mit Unix-Domain-Sockets. Ganz wichtiges Stichwort ist listen.backlog von PHP-FPM. Wenn ein großer Request-Spike kommt und PHP nicht schnell genug mit dem accept() ist, dann kann dieses Backlog voll laufen und der nginx wirft den 504er. Das passiert selbst dann, wenn die Requests theoretisch innerhalb kürzester Zeit abgearbeitet werden könnten, weil die Request-Rate direkt nach dem Spike wieder abnimmt.

  • Ah Danke, net.core.somaxconn stand auf dem alten Standardwert von 128, ich habe diesen jetzt auf den neuen Standardwert von 4096 gesetzt.

    Dies verzögert Anfragen, anstatt diese mit bad gateways zu beenden. Also das eigentliche Problem ist damit nicht behoben.

    Hier auch noch mal insgesamt wie lange es braucht bis die komplette Seite geladen ist mit ImageProxyAction und dem PHP Script von oben, welches direkt die Static URL zurückgibt.

    Ich habe es auf TCP geändert, durch das Ändern von dbHost auf 127.0.0.1, ich konnte aber keinen Unterschied feststellen.

    Was mir auch noch aufgefallen ist beim Durchsuchen des MySQL logs, ist das die erstellte Datenbank Verbindung durch ImageProxyAction nicht sofort geschlossen wird.

    Foren
    WSC 5.xWSC 5.x WCF 4.x phpBB 3.x XenForo 1.x
    hayday-forum.detrueadventure.de/forum vw-page.com msx-125.de/forum mineyourmind.net/forum
    brawlstar.denc750.de/forum kadett-forum.de xv950r.de/forum
    clashroyaleforum.dehonda-crosstourer.de/forum dr-125.de/dr125-forum
    clashofclansforum.decb-1100.de/forum
    boombeachforum.dexsr900.de/forum
    mt09.de/forumswm-motorrad.com/forum
    mt10-forum.de
    • Offizieller Beitrag

    Hallo,

    Hier auch noch mal insgesamt wie lange es braucht bis die komplette Seite geladen ist mit ImageProxyAction und dem PHP Script von oben, welches direkt die Static URL zurückgibt.

    da ist definitiv etwas kaputt konfiguriert. Ich habe es gerade mal in einer WoltLab Cloud-Instanz mit 400 Image-Proxy-Bildern auf der Seite getestet:

    Alle Bilder waren bereits heruntergeladen (d.h. lokal in der Instanz gecached). Neu geladen habe ich die Seite über „Cache leeren und aktualisieren“. Alle Requests waren erfolgreich:

    Code
    $ journalctl -u haproxy --since '09:05:55' --until '09:06:15' |grep '*snip*' |halog -st
    200 709
    301 701
    1410 lines in, 2 lines out, 0 parsing errors

    98.7% der Requests wurden in weniger als 1 Sekunde beantwortet. 99.9 in 6,1 Sekunden. 100% in 12,1 Sekunden:

    Das ist jetzt nicht gerade spektakulär schnell, aber definitiv nicht im Bereich von Minuten.

    Ich habe es auf TCP geändert, durch das Ändern von dbHost auf 127.0.0.1, ich konnte aber keinen Unterschied feststellen.

    Gemeint war hier die Kommunikation zwischen dem FastCGI-Gateway (z.B. nginx) und PHP-FPM, nicht zwischen PHP und MySQL.

    Was mir auch noch aufgefallen ist beim Durchsuchen des MySQL logs, ist das die erstellte Datenbank Verbindung durch ImageProxyAction nicht sofort geschlossen wird.

    Die Verwaltung der Datenbankverbindung wird von PHP übernommen. Die Verbindung wird durch PHP automatisch am Ende des Requests geschlossen. Wenn das nicht erfolgt, dann weil aus Sicht von PHP der Request noch nicht abgeschlossen ist.

  • Hm, wie viele Datenbankverbindungen hat es bei dir aufgebaut?

    Was ich mir vorstellen kann ist das die MySQL Anfragen bei dir schneller verarbeitet werden und daher die Worker, sowie Verbindungen früher freigegeben werden.

    Foren
    WSC 5.xWSC 5.x WCF 4.x phpBB 3.x XenForo 1.x
    hayday-forum.detrueadventure.de/forum vw-page.com msx-125.de/forum mineyourmind.net/forum
    brawlstar.denc750.de/forum kadett-forum.de xv950r.de/forum
    clashroyaleforum.dehonda-crosstourer.de/forum dr-125.de/dr125-forum
    clashofclansforum.decb-1100.de/forum
    boombeachforum.dexsr900.de/forum
    mt09.de/forumswm-motorrad.com/forum
    mt10-forum.de
  • Ich habe jetzt den Profiler angeschmissen und das Problem gefunden.

    Das Problem liegt an der langsamen initBlacklist, welche in neueren WoltLab Versionen überarbeitet ist und die Hostname Blacklist entfernt. Dies hat dazu geführt, das jede Proxy Anfrage ewig gedauert hat und so die Worker nicht schnell genug wieder zur Verfügung standen.

    Ich habe diese Methode jetzt mit der neusten ausgetauscht bis wir dazu kommen das Forum zu aktualisieren.

    Danke für das testen und helfen.

    Foren
    WSC 5.xWSC 5.x WCF 4.x phpBB 3.x XenForo 1.x
    hayday-forum.detrueadventure.de/forum vw-page.com msx-125.de/forum mineyourmind.net/forum
    brawlstar.denc750.de/forum kadett-forum.de xv950r.de/forum
    clashroyaleforum.dehonda-crosstourer.de/forum dr-125.de/dr125-forum
    clashofclansforum.decb-1100.de/forum
    boombeachforum.dexsr900.de/forum
    mt09.de/forumswm-motorrad.com/forum
    mt10-forum.de
  • Ich habe diese Methode jetzt mit der neusten ausgetauscht bis wir dazu kommen das Forum zu aktualisieren.

    Die Option BLACKLIST_HOSTNAMES wieder leer zu machen sollte das Problem ebenfalls beseitigen, denn dann wird gethostbyaddr garnicht mehr ausgeführt. :)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!