Το WordPress έχει σχεδιαστεί για να είναι ένα ευέλικτο application framework, αλλά αυτή η ευελιξία δεν είναι πάντοτε καλή, ειδικά για την βάση δεδομένων. Καθώς ο ιστότοπός σας αναπτύσσεται οι πίνακες wp_postmeta και wp_options αποκτούν εκατομμύρια γραμμές κώδικα.
Ένας ιστότοπος μπορεί να φαίνεται γρήγορος στο frontend λόγω της προσωρινής αποθήκευσης σελίδων (page caching), μας δείχνει ότι μια βάση δεδομένων δυσκολεύεται να βρει δεδομένα.
Σε μια τεράστια βάση δεδομένων χωρίς indexing η MySQL θα πρέπει να πραγματοποιεί μια πλήρη σάρωση πίνακα. Αυτό σημαίνει ότι εξετάζει κάθε γραμμή στον δίσκο για να βρει μια αντιστοιχία για το ένα ερώτημά σας. Εάν έχετε 2,5 εκατομμύρια γραμμές post meta, αυτή η διαδικασία θα είναι απίστευτα αργή και απαιτεί πολλούς πόρους.
Το wp_options και το buffer του 1MB
Το wp_options μεγαλώνει και αποκτάει νέες εγγραφές με κάθε plugin που εγκαθιστάτε και με κάθε ρύθμιση που κάνετε.
Ο πίνακας wp_options είναι αναμφισβήτητα η πιο συνηθισμένη πηγή επιβράδυνσης. Το WordPress έχει σχεδιαστεί για να υποβάλλει ερώτημα σε κάθε γραμμή όπου η αυτόματη φόρτωση είναι στο ‘ναι’ (autoload = ‘yes’ ) σε κάθε φόρτωση σελίδας για τη συμπλήρωση του object cache.
Ανάλογα με την πλατφόρμα φιλοξενίας που χρησιμοποιείτε αυτές οι τιμές του autoload μπορούν να αποθηκευτούν σαν μία γραμμή στο μόνιμο object cache. Εδώ είναι που έρχεται το όριο του buffer στο 1MB σαν ένα κρίσιμο προστατευτικό κιγκλίδωμα. Εάν το συνολικό μέγεθος των δεδομένων που φορτώνονται αυτόματα υπερβαίνει αυτό το όριο του 1MB, το επίπεδο της προσωρινής μνήμης μπορεί να απορρίψει το αίτημα. Αυτό αναγκάζει το WordPress να υποβάλλει επανειλημμένα ερωτήματα στη βάση δεδομένων για ένα τεράστιο σύνολο δεδομένων που φορτώνεται συνεχώς, με αποτέλεσμα ένα loop αποτυχημένων αιτημάτων που οδηγούν σε σφάλματα 502 Bad Gateway.
Ακόμα κι αν παραμείνετε κάτω από το όριο του 1MB, ένα υπερβολικά μεγάλο wp_options καθιστά τα index lookups λιγότερο αποτελεσματικά. Η διατήρηση ενός πίνακα wp_options με λίγα autoload = ‘yes’, ιδανικά κάτω από τα 700 kb, είναι απαραίτητη για τη διατήρηση ενός υγιούς πobject cache και τη διασφάλιση ενός γρήγορου Time to First Byte (TTFB) για όλα τα αιτήματα.
Ο εφιάλτης του wp_postmeta
Ο πίνακας wp_postmeta είναι ένας “κάθετος” πίνακας που χρησιμοποιεί ζεύγη key/value. Από προεπιλογή, η στήλη meta_value δεν ευρετηριάζεται επειδή χρησιμοποιεί έναν τύπο δεδομένων longtext.
Εάν τρέξετε ένα meta_query που φιλτράρει κατά meta_value, όπως η αναζήτηση όλων των προϊόντων εντός ενός συγκεκριμένου εύρους τιμών, η MySQL αναγκάζεται να σαρώσει κάθε γραμμή metadata. Όταν ο πίνακάς σας έχει εκατομμύρια γραμμές, αυτά τα ερωτήματα μπορεί να χρειαστούν χρόνο για να εκτελεστούν.
Τι μπορείτε να κάνετε;
Αν δεν γνωρίζετε την δομή μιας βάσης δεδομένων του WordPress καλύτερα να μην κάνετε τίποτα. Αν γνωρίζετε, πάρτε ένα full backup και χρησιμοποιήστε το WP DB Cleaner (Advanced Database Cleaner – Optimize & Clean Database to Speed Up Site Performance), ή το phpMyAdmin.
Προχωρήστε με δική σας ευθύνη, ή βρείτε κάποιον να το κάνει για εσάς.
Ο Γιώργος ακόμα αναρωτιέται τι κάνει εδώ….
