Template ist extrem langsam und ich weiß nicht warum

  • Hallo,

    hab mir ein kleines Template gemacht, damit ich meine Termine über das Plug-In "RS Event" auf einer Seite (page.php) ausgeben kann.

    Das funktioniert auch über das Template sehr gut. Allerdings dauert es bis zu 10 Sekunden(!) bis die Seite angezeigt wird. Und ich weiß nicht warum. Alle anderen Seiten (und Artikel) werden normal angezeigt. Es muss also am Template liegen.

    Hat jemand einen Tipp, was im Code die Bremse sein könnte?

    • Anzeige

    Hallo!

    Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

    • ✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
    • ✔️ Deutsche Server & DSGVO-konform
    • ✔️ Persönlicher Support (kein 0815-Ticket-System)

    Mehr erfahren

  • Das einzige, was hier richtig viel Zeit kosten kann ist das hier:

    PHP
    <?php ec3_get_events(50); ?>

    Ich nehme mal an, das man damit 50 Termine abholen kann. Wenn das zugrunde liegende Plugin "schlecht" im Sinne von Performance geschrieben ist, dann macht es dazu 50 Abfragen in die Datenbank, was deine Zeit problemlos erklären würde.
    Ich würde den Code durchsehen, der dabei ausgeführt wird und/oder den Autor befragen, wie das schneller zu machen ist.

  • Ich bin mal so frei: :-D


    Viel Spaß beim durchsehen codestyling. ;-) (Die SQL-Query sieht auf den 1. Blick okay aus)

  • Oh, jetzt hab ich einen Fehler gemacht. Das war mein altes Template vom Plugin "Event Calendar". Ich war mit dem Plug-In aber extrem unzufrieden und bin auf das "RS Event" gewechselt.

    Hier nun das richtige Template, das extrem lange braucht.

  • Es gibt mindestens 2 Kandidaten für Performance Verlust:

    1. Der Query selbst
    2. Die loop über die Ergebnismenge (max. 50)


    Query

    Ein typischer LEFT JOIN über 3 Tabellen. Dabei fällt auf, dass es essentiell ist, das sowohl die Spalten p.post_status (WordPress posts Tabelle) als auch s.end (Calendar Tabelle) einen Vollindex benötigen, damit das schnell gemacht werden kann. Die beiden JOIN's provozieren aber auch einen full table scan und sind deshalb performancetechnisch gesehen suboptimal.

    Man müsste mit der Datenbank von funkytown mal einen Test machen und die Zeit für den query stoppen und ausgeben lassen. Die Datenmenge and Posts, Usern und Kalendareinträgen sind hier essentielle Größen, da das ein kubische Komplexität O(n^3) hat!

    die loop
    Es werden alle gefunden Ergebnisse mittels einer Funktion, die ich nicht kenne, pro Zeile und pro Element der Zeile mittels Templates formatiert und ausgegeben. Was genau da passiert, kann ich nicht sehen, könnte je nach Implementierung (regexp Ersetzungen) bei 50 Eintragen und 5 Elementen auch etwas brauchen.

    Um das zu beschleunigen, kommt man um die Originaldatenbank nicht drumrum, denn die Tests sind notwendig. Die oben angegebenen Indizierungen in der DB nachzurüsten, kann aber nicht schaden und könnte das Problem schon deutlich mindern.


  • Wenn man da 'zig ID's mit oder zusammenpappt, dann kann die Abfrage performace-technisch nur in die Hose gehen.
    Und die nachfolgende Schleifenbehandlung der Ergebnisse benutzt massenweise array preg_exp, die man auch messen müsste.
    Ohne die Eckdaten der Datenbank (Postanzahl, Kalendereinträge usw.) die hier eine Rolle spielen, kann man sich kein Bild machen. Beide Plugins sind aber von der Art und Weise der Datenabfrage und Aufbereitung her optimierungsbedürftig.

Jetzt mitmachen!

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