Get Recent Comments gehört mE mit zu den besten Kommentarplugins im WordPressbereich. Es wartet nebst der visuellen Trennung von Trackbacks und Kommentaren mit einer vorzüglichen Bedienoberfläche für den Admin auf.
Wie jedoch am Wochenende in den zahlreichen WordPress-Artikeln zur Problemzone Plugin-Perfomance beschrieben, gehören gerade Kommentarplugins zu potenziellen Ressourcenfressern. Dabei kommt es nicht nur auf die Anzahl der Queries (Anzahl der sich wiederholenden Datenbankabfragen) an, sondern auch auf die Anzahl der zu durchsuchenden Datensätze. Es ist also gänzlich etwas anderes, wenn man sich die letzten X Kommentare anzeigen lässt und dabei 100 oder aber 100.000 Datensätze durchforsten muss.
So ein Kommentator (king of Fool) beim Plugin Developer zum o.g. Tool:
Du willst nicht abgehängt werden, wenn es um KI, Green Tech und die Tech-Themen von Morgen geht? Über 12.000 Vordenker bekommen jeden Tag die wichtigsten News direkt in die Inbox und sichern sich ihren Vorsprung.
Nur für kurze Zeit: Anmelden und mit etwas Glück Apple AirPods gewinnen!
Mit deiner Anmeldung bestätigst du unsere Datenschutzerklärung. Beim Gewinnspiel gelten die AGB.
Google lässt dich jetzt selbst bestimmen, welche Quellen du in der Suche häufiger siehst. Mit zwei schnellen Klicks kannst du BASIC thinking kostenlos als bevorzugte Quelle hinzufügen und damit unabhängigen Tech-Journalismus unterstützen. Vielen Dank!
The plugin works great but keep in mind that the mysql query is extremely inefficient. If you only have a few hundred comments, you might not notice any issues – however I just spent a few hours debugging a site that has over 50,000 comments. It turns out the plugin query was processing 145,000 db rows just to get the last 5 comments, plus it was filesorting them for an added performance hit.
How we solved it:
1. We added an index by comment_date to the wp_comments table. This immediately eliminated the filesort.
2. „WHERE DATE_SUB(CURDATE(),INTERVAL 1 DAY) < = comment_date AND"¦"? to the plugin query (in two places). Now instead of reading 145,000 rows, it reads 415.
Habe diese Anpassungen entsprechend vorgenommen (DB vorher gesichert 😉 und unter Dialoge, wo das Plugin läuft, habe ich nach einigen Minitests feststellen können, daß in der Tat der Seitenaufbau regelmäßig um 0.5-1 Sekunde schneller läuft.
