Продуктивність опцій у WordPress - WP Magazine
Про WordPress українською мовою
Продуктивність опцій у WordPress
Таблиця з опціями WordPress містить всі налаштування вашого сайту, тем і плагінів. У ній можуть зберігатися як прості прапорці (так/ні), і дані більших розмірів, іноді навіть логи. API для роботи з опціями WordPress дуже простий, його можна резюмувати в два рядки:
Але це лише поверхня, тому що внутрішній механізм роботи з опціями набагато складніший, і саме через це багато хто навіть досвідчені розробники роблять ряд критичних помилок, які можуть призвести до уповільнення WordPress сайтів та надмірного споживання пам'яті.
Недостатня помилка: Завантажені пам'яті розмір 134217728 bytes exhausted
Звичайно, можна звернутися до хостинг-провайдера, попросити підняти ліміт пам'яті до 256 мегабайт, потім ще більше, ще й ще. Але у такий спосіб ви тимчасово приховуєте проблему, а не вирішуєте її.
Як працюють опції у WordPress
У WordPress є таблиця wp_options, її структура досить проста:
При зверненні до функції get_option() в WordPress ми отримуємо значення опції по ключу з бази даних, але тут варто пам'ятати одну дуже важливу річ: опції з прапорцем autoloadпідвантажуються в пам'ять автоматично при завантаженні ядра WordPress, за це відповідає внутрішня функція wp_load_alloptions().
Це означає, що при зверненні до опції siteurl в нашій темі або в плагіні WordPress, результат буде виданий одразу з кешу об'єктів, а не з бази MySQL.
Такий підхід є безумовним плюсом для тих опцій, які ми (ядро, наша тема, наші плагіни) маємо намір використовувати для відображення поточної сторінки WordPress. Це запобігає зайвим походам у базу даних MySQL за кожною необхідною опцією.
Але що щодо тихопцій, які ми завантажили на згадку, але так ними і не скористалися? Адже вони просто споживають наші ресурси.
Що з цим робити?
Навряд чи знайдеться така сторінка, для відображення якої були б потрібні абсолютно всі опції з прапором autoload , і напевно більшість сторінок на вашому WordPress сайті використовують набагато менше половини всіх авто-підвантажуваних опцій, і це нормальна практика.
Проблеми з продуктивністю виникають далеко не через їхню кількість. Повернімося до нашого API для роботи з опціями WordPress, візьмемо простий плагін, який вирішив записати в опцію foo значення bar:
Багато розробників навіть не замислюються над тим, чи така опція стане підвантажуватися автоматично. Чи потрібна ця опція для відображення більшості сторінок на сайті, і скільки «зайвої» пам'яті буде споживати ця опція.
Запам'ятайте, що при використанні функцій update_option() або add_option() , прапор autoload ставитьсяза промовчанням для нових опцій. А при деактивації чи видаленні теми чи плагіна, опція (як правило) нікуди не зникає. Якщо вам потрібно було створити опцію без autoload , то скористайтеся четвертим аргументом функції add_option().
Звичайно для опції foo-bar це всього близько 6 байт пам'яті (три байта для ключа і три для значення), і навіть тисяча таких опцій (
6 кілобайт) практично ніяк не позначаться на швидкість роботи сайту та споживання пам'яті, але давайте розглянемо цікавіший приклад.
На жаль, їхній хостинг-провайдер перевів їх на дорожчий тарифний план, потім ще дорожче і ще, посилаючись на те, що WordPress «ненажерливий до серверних ресурсів». Вони деактивували всі плагіни, порушили тему за умовчанням, але це не допомогло.
" data-medium-file="https://wpmag.ru/wp-content/uploads/sites/13/2015/07/wordpress-memory-usage-debug-300x37.png" data-large-file="https://wpmag.ru/wp-content/uploads/sites/13/2015 /07/wordpress-memory-usage-debug-1024x128.png" src="https://wpmag-22.cdn.pjtsu.com/wp-content/uploads/sites/13/2015/07/wordpress-memory- usage-debug.png?w=780" alt="Потреблення пам'яті в WordPress" width="766" height="95" class="size-full wp-image-34210" srcset="https://wpmag-22 .cdn.pjtsu.com/wp-content/uploads/sites/13/2015/07/wordpress-memory-usage-debug.png?resize=1588x198 1588w, https://wpmag-22.cdn.pjtsu.com/ wp-content/uploads/sites/13/2015/07/wordpress-memory-usage-debug.png?resize=790x98 790w, https://wpmag-22.cdn.pjtsu.com/wp-content/uploads/sites /13/2015/07/wordpress-memory-usage-debug.png?resize=530x66 530w, https://wpmag-22.cdn.pjtsu.com/wp-content/uploads/sites/13/2015/07/ wordpress-memory-usage-debug.png?resize=400x49 400w, https://wpmag-22.cdn.pjtsu.com/wp-content/uploads/sites/13/2015/07/wordpress-memory-usage-debug .png?resize=320x39 320w" sizes="(max-width: 1588px) 100vw, 1588px" />
Потреба пам'яті в WordPress
Якщо розробник тут поставив ні для прапора автозавантаження, це вирішило проблему для всіх сторінок, крім сторінки оплати, так як на ній ми все рівно намагалися завантажити великий обсяг пам’яті.
Удавши цю опцію ціликом із бази даних, і вдавши плагін, який її згенерував, нам вдалося вирішити проблему з використанням пам’яті та повернути ліміт до стандартних 32 мегабайт. Якщо ж говорити про саму задачу, то багато логічне було б вирішити її за допомогою довільної таблиці в MySQL або за допомогою запису значень у файлі на диску.
Як знайти подібні опції?
За допомогою запиту в базу даних MySQL можна отримати список найбільших за обсягом опцій з флагом автозавантаження:
Всі ці опції будуть завантажуватись при кожному запиті на ваш WordPress сайт. У даному прикладі все цілком пристойно, 23кб не такий суттєвий об'єм, хоча якщо ви, наприклад, не використовуєте плагін Jetpack, то опцію jetpack_file_data можна сміливо видалити. Якщо у вас не активована тема Weaver II, опцію weaverii_settings можна видалити.
На жаль, не завжди з назв опцій можна зрозуміти до якої теми чи плагіна вона відноситься, і тоді доводиться виконувати пошук за вихідним кодом.
Також не слід видаляти опції ядра WordPress, а якщо ви помітили, що деякі з них почали споживати занадто багато пам'яті, то ймовірно проблема в сторонньому плагіні, темі або конфігурації сервера.
Наприклад, нещодавно ми зіткнулися з опцією ядра cron (планувальник завдань WordPress) яка споживала більше 8 мегабайт пам'яті. З'ясувалося, що хостинг-провайдер відключив клієнту виконання cron-задач, а нові завдання продовжували додаватися до цієї опції щодня. Вирішити проблему вдалося просто увімкнувши планувальник завдань WordPress.
Висновок
Якщо ви помітили, що ваш сайт на WordPress згодом став повільним і використовує надмірну кількість пам'яті, то не поспішайте кидатися грошима у вашого хостинг-провайдера. Можливо, проблему можна вирішити більш дешевим і надійним способом.