Я уважно ознайомився зі споживанням пам'яті Wordpress. На моєму сайті, здається, що на кожне звернення до сторінки виділяється 20 Мб оперативної пам’яті, просто підготувати зручне середовище для запуску всіх плагінів. Я склав це так:
Не існує жодного місця для оптимізації, немає жодного поганого хлопця, який їсть більшу частину пам'яті. Все споживання поширюється на багато-багато багатьох модулів PHP.
Як ми можемо змусити Wordpress ініціалізувати своє середовище в пам’яті лише один раз, а потім повторно використовувати його для кожного звернення? Я не хочу, щоб повільний PHP їв 20 Мб при кожному натисканні користувача - навіть на сервері з великою кількістю пам’яті потрібні секунди, щоб виконати всю цю роботу. В основному вам потрібні шматки пам’яті лише для читання, які можна використовувати повторно.
Також ... чому 20 Мб? Чи може хтось дати зрозуміти це?
Редагувати: Ось результат виходу WinCacheGrind на Wordpress, який працює на моїй розробній машині (набагато швидше, ніж на спільному хостингу). Як бачимо, для отримання HTML-адреси основної сторінки потрібна секунда розчавлення. Уповільнити це шляхом спільного хостингу, і у вас є рецепт проблем. Я вибрав метод, який займає більшу частину часу. Як би ви вирішили оптимізувати це?
Редагувати: Ось статистика запитів із цього фантастичного інструменту для профілювання function.php .
Завантаження: 12 запитів - 532 мс - 19,1 МБ - 43 звернення в кеш / 53 Запит: 15 запитів - 563ms - 19.0MB - 72 хіти кешу / 86 Відображення: 21 запит - 705 мс - 19,2 МБ - 234 хіти кешу / 257
Редагувати: Ви хочете побачити щось гарантоване, яке б вас змусило? Вставте ці рядки в кінці index.php:
echo "<pre>\n";
print_r(get_defined_vars());
echo "</pre>\n";Я намагався підрахувати, скільки разів зберігається тіло поточної публікації в пам'яті. Я нарахував 20 екземплярів. Тоді я зрозумів, що PHP має підрахунок посилань, тому кількість копій зменшилася до трьох: дві, здається, є в WP_Query, одна - в об'єктному кеші. Я розслідую далі.
Тому я вважаю, що WordPress потребує рефакторингу, спрямованої на проблеми пам'яті. Ви більше не можете звинувачувати його споживання у великій складності того, що він робить. Це просто робить купу речей не так .
Редагувати: Після дня спроби розібратися в цьому, ось мої висновки:
1) 88% усієї пам’яті надходить з вимагають або включають або включають_once тип дзвінків:
2) Файл php включає в себе трапляються в основному під час першої частини подання запиту (не дивно), де також з'їдається вся пам'ять:
3) Досить цікаво побудувати всі функції, які виконуються під час подання запиту. Всього понад 12000 дзвінків. Я стрибав їх, щоб зробити його більш помітним (вісь рівня - це в основному глибина стека):
4) Єдиний шлях вперед, про який я можу подумати - це мінімізація кількості включених .php файлів. Якщо я розділити функції на файл, з якого вони вийшли, ви можете побачити, що багато файлів потрапляють максимум один або два рази. Нам потрібен спосіб, як пропустити тих, коли вони не потрібні. Наприклад, мій плагін для віддаленого резервного копіювання бази даних завантажується та реєструється, просто ніколи його не використовувати. Ось наведений вище сюжет, розділений на ім'я файлу:
Я пропоную винагороду, вартую всієї своєї репутації :) за оновлення, які призведуть до скорочення пам’яті моїх блогів на 30% або більше.
Редагувати: я встановив WP 3.1, ось порівняння зі старою версією.
Синій - WP 3.1, червоний - 3.0.4. Нова WP швидша, але також їсть більше пам’яті.
Ось список за включенням файлу.
Це дозволить мені зрозуміти, скільки пам’яті споживає «Все в одному SEO-пакеті» - одна дорога буде використовувати лише частину функціональності плагіна, щоб отримати те, що я хочу. Також мої власні плагіни здаються досить поганими.
Я хотів би спробувати умовне завантаження, наприклад, comment.php (я забороняю коментарі на своєму блозі) та декількох інших. Я видалив увесь застарілий код. Я обрізав kses.php, щоб тільки завантажувати його глобальні таблиці за запитом. Я спростив l10n (я не роблю локалізації), змушуючи його функції повертати рядки відразу, без пошуку. Я ще далекий від 30% позначки, яку я довільно встановив.
Редагувати: я завантажив і ввімкнув APC із налаштуваннями за замовчуванням (32 Мб кешу опкоду). Ось порівняння:
Ви можете бачити, що завантаження коду прискорилося масово, і код також займає менше місця в пам’яті (можливо, тому, що ми маємо справу саме з опкодами, а не з оригінальним джерелом). Однак споживання пам'яті все ще досить високе.