Unser WordPress-Blog lief einwandfrei, bis wir ungefähr 30.000 Beiträge importierten. Die Suche auf der Website wurde danach sehr langsam.
Das
Laden einer Seite mit dem Such- und Filter-Widget dauert ungefähr 4 Sekunden.
- 18 Sekunden, um die Suchergebnisse zurückzugeben.
Wichtige Plugins, die wir verwenden:
Benutzerdefinierte Beitragstypen - Wir haben nur einen benutzerdefinierten Beitragstyp, der im Blog verwendet wird.
Erweiterte benutzerdefinierte Felder - Wir haben eine Reihe von benutzerdefinierten Feldern, die durchsucht und gefiltert werden können.
Von uns verwendete Such-Plugins:
Alles durchsuchen - Tags, Autoren und Kommentare sind für die Suche aktiviert. Post-Inhalt, Titel und benutzerdefinierte Felder können standardmäßig durchsucht werden.
Search & Filter Pro - wird verwendet, um unser Such- und Filter-Widget zu erstellen und Filterregeln festzulegen.
Caching:
Wir verwenden Memcache als steckbaren Cache für WP sowie als persistente Cache-Lösung.
Umgebung:
Physischer Server: AWS t2.small; 2 GB Speicher; CPU 1 Kern bis 3,3 GHz
Betriebssystem: Windows Server 2012
Webserver: IIS 8.5
PHP 5.6.22
Wordpress 4.6.1 MySQL 5.6.27 (dedizierte RDS-Instanz)
Wir haben eine ziemlich begrenzte Nutzerbasis und beobachten keine signifikanten Spitzen bei der Nutzung der Serverressourcen sowohl für den App-Server als auch für den DB-Server.
Hier ist die am längsten laufende SQL-Abfrage, die ausgeführt wird, wenn Benutzer eine Suche auf einer Website durchführen:
SELECT SQL_CALC_FOUND_ROWS distinct wp_posts.ID
FROM wp_posts
LEFT JOIN wp_postmeta
ON wp_posts.id = wp_postmeta.post_id
LEFT JOIN wp_term_relationships AS trel
ON ( wp_posts.id = trel.object_id )
LEFT JOIN wp_term_taxonomy AS ttax
ON ( ( ttax.taxonomy = 'post_tag' )
AND trel.term_taxonomy_id = ttax.term_taxonomy_id )
LEFT JOIN wp_terms AS tter
ON ( ttax.term_id = tter.term_id )
LEFT JOIN wp_comments AS cmt
ON ( cmt.comment_post_id = wp_posts.id )
LEFT JOIN wp_users AS u
ON ( wp_posts.post_author = u.id )
WHERE 1 = 1
AND ( ( wp_posts.id IN (<LIST_OF_POST_IDS>)
AND (( (( ( wp_posts.post_title LIKE '%searchterm%' )
OR ( wp_postmeta.meta_value LIKE '%searchterm%' )
OR ( wp_posts.post_content LIKE '%searchterm%' ) ))
OR (( tter.name LIKE '%searchterm%' ))
OR ( (( cmt.comment_content LIKE '%searchterm%' ))
AND cmt.comment_approved = '1' )
OR (( u.display_name LIKE '%searchterm%' )) ))
AND wp_posts.post_type = 'generalpost'
AND (( wp_posts.post_status = 'publish' )) )
AND post_type != 'revision' )
AND post_status != 'future'
ORDER BY wp_posts.post_date DESC
LIMIT 0, 15;
In der Wordpress DB-Dokumentation finden Sie eine Schema-Referenz
Diese Abfrage ist für etwa 65% der Ladezeit der Suchergebnisseite verantwortlich (12 von 18 Sekunden).
Derzeit haben wir nur einen benutzerdefinierten Beitragstyp, und nur dieser muss durchsuchbar sein. Jeder benutzerdefinierte Beitragstyp enthält 18 Datensätze in wp_postmeta. Von diesen 18 Feldern müssen nur 4 durchsuchbar sein - und dies ist eine mögliche Möglichkeit, die Suche zu beschleunigen.
In meinen Tests diese Klausel hinzufügen
`AND meta_key in ('cust_field1', 'cust_field2', 'cust_field3', 'cust_field4',)`beschleunigte die Abfrage tatsächlich fast zweimal. Plugin-Entwickler wurden kontaktiert, um eine Funktion zur Unterstützung des Ausschlusses von Metafeldern zu implementieren.
Ich habe auch einen zusammengesetzten Index für die Spalten post_id, meta_key und meta_value erstellt, der die Abfragezeit um weitere 5-10% verkürzt .
Was wären die anderen Möglichkeiten, um die Suche mit dieser Datenmenge effizienter zu gestalten, damit die Benutzererfahrung nicht beeinträchtigt wird?