Рефакторинг Wordpress для повышения производительности памяти [закрыт]
Я внимательно изучил потребление памяти Wordpress. На моем сайте кажется, что для каждой страницы удаётся выделить 20 МБ ОЗУ, чтобы подготовить удобную среду для всех подключаемых модулей. Я построил ее так:
http://zenka.net/roman/wordpress_memory_consumption.gif
Нет ни одного места для оптимизации, ни одного плохого парня, который ест большую часть памяти. Потребление распространяется на многие многие php-модули.
Как мы можем заставить Wordpress инициализировать свою среду в памяти только один раз, а затем повторно использовать ее много раз для каждого попадания? Я не хочу, чтобы медленный PHP питался 20 МБ при каждом нажатии на пользователя - даже на сервере с большим количеством памяти, для выполнения всей этой работы требуется несколько секунд. Вам в основном нужны куски памяти, доступные только для чтения, которые могут быть повторно использованы.
Также ... почему 20 МБ? Может ли кто-нибудь объяснить это?
Изменить: Здесь вывод WinCacheGrind на Wordpress работает на моей машине разработки (намного быстрее, чем на общем хостинге). Как вы можете видеть, для получения HTML-страницы главной страницы требуется еще одна секунда хруста. Замете это на общий хостинг, и у вас есть рецепт неприятностей. Я выбрал метод, который занимает большую часть времени. Как бы вы решили оптимизировать это?
http://zenka.net/roman/wordpress_cpu_usage.gif
Изменить: Вот статистика запросов от этот фантастический инструмент профилирования functions.php .
Загрузка: 12 запросов - 532ms - 19.1MB - 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% всей памяти поступает из типа вызовов или include или include_once:
http://zenka.net/roman/wordpress_memory_requires.gif
2) Файл php включает в себя в основном во время первой части обслуживания запроса (что не удивительно), в котором также содержится вся память:
http://zenka.net/roman/wordpress_includes.gif
3) Весьма интересно построить все функции, выполняемые во время выполнения запроса. Всего более 12000 вызовов. Я дрожал их, чтобы сделать его более заметным (ось уровня - это в основном глубина стека):
http://zenka.net/roman/wordpress_functions.gif
4) Единственный способ, о котором я могу думать, - это минимизировать количество файлов .php. Если я разделил функции на каждый файл, из которого они пришли, вы можете увидеть, что многие файлы попадают один или два раза больше. Нам нужен способ пропустить те, когда они не нужны. Например, мой плагин резервного копирования базы данных загружается и регистрируется, чтобы его никогда не использовали вообще. Ниже приведен фрагмент файла по имени файла:
http://zenka.net/roman/wordpress_functions_files.gif
Я предлагаю награду за всю мою репутацию :) за рефакторинг, который приведет к сокращению объема памяти в блогах на 30% и более.
Изменить: я установил WP 3.1, вот сравнение со старой версией.
http://zenka.net/roman/wordpress_memory_usage_comparison.png
Синий - WP 3.1, красный - 3.0.4. Новый WP быстрее, но также и больше памяти.
Вот список по файлу include.
http://zenka.net/roman/wordpress_3.1_vs_3.0.4_mem_by_file. PNG
Это позволяет мне понять, сколько памяти съедено «пакетом« Все в одном SEO »- одним из способов было бы использовать только часть функциональности плагина, чтобы получить то, что я хочу. Кроме того, мои собственные плагины выглядят довольноплохой.
Я хотел бы попробовать условную загрузку, например. comment.php (я запрещаю комментарии в своем блоге) и несколько других. Я удалил весь устаревший код. Я урезал kses.php, чтобы загружать его глобальные таблицы по требованию. Я упростил l10n (я не локализую), и его функции сразу возвращают строки, без поисков. Я все еще далек от 30% -ной отметки, которую я произвольно установил.
Изменить: я загрузил и включил APC с настройками по умолчанию (32 МБ кэша операций с кодами операций). Вот сравнение:
http://zenka.net/roman/3.1_without_with_apc.png
Вы можете видеть, что загрузка кода ускоряется массово, а код также занимает меньше места в памяти (вероятно, потому, что мы имеем дело только с кодами операций, а не с исходным исходным кодом). Однако потребление памяти довольно велико.
8 ответов
Не стоит беспокоиться. WordPress не ест много памяти, потому что. Он ест много памяти, потому что у него много функций под капотом.
Гораздо проще и эффективнее кэшировать результаты (сгенерированные страницы) с помощью статического кеш-плагина и обслуживать их. Таким образом, большинство посетителей даже не попадет в сам WP.
И вот почему я думаю, что WordPress в серьезной необходимости переписать. Ты можешь больше не обвиняют в потреблении памяти от явной сложности того, что он делает. Это просто неправильно.
Какой наивный вывод. Прочитайте Вещи, которые вы не должны делать, часть I .
Спасибо за графики использования памяти.
Много позже отредактируйте: Autommatic выпустила библиотеку под названием префикс , которая кажется делать то, о чем вы просите: загрузка кода WordPress в ОЗУ только один раз.
Начиная с WordPress 3.2, PHP 5.2 будет минимальным требованием. Я думаю, что под нашими поясами бит ядра может начать реструктурироваться и использовать классы с автоматической загрузкой. Это позволило бы избежать загрузки некоторых фрагментов кода, если они не были на самом деле . Например, если в представлении страницы не было никаких вложений или галерей, мы могли бы избежать загрузки большого количества медиа-кода.
Однако, даже если они решат пойти по этому маршруту, я ожидаю, что это будет медленная эволюция (как и большинство других изменений под капотом, которые произошли). Это потребует перетасовки вокруг места большого количества файлов и кода, которые могли бы сломаться назад для некоторых плагинов.
Часть проблемы (если ее действительно можно назвать) заключается в том, что без такой условной загрузки базовая инфраструктура не может заранее знать, какие функции ей понадобятся или не нужны для создания представления содержимого , Поэтому нужно загружать множество функций на всякий случай .
Как мы можем заставить Wordpress инициализировать его окружение в памяти только один раз, и затем повторно использовать его много раз для каждого хит?
Это называется кодовым кэшированием.
вам, вероятно, не удастся значительно сократить использование барабанов.
Но если вы используете mod_php, вы можете вместо этого перейти на mod_fcgid.
в то время как mod_php немного медленнее, он загружает php, даже когда это не нужно, например, показ изображений, статических файлов или даже кеширование. Если у вас много запросов, это много бара.
Использование fcgid значительно уменьшит это.
также, используя статический кеш (например, w3total cache), вы избежите вызова php вообще , что является действительно большим преимуществом: меньшее использование ram, меньше db-соединений.
га. Сейчас я работаю над веб-приложением, так что я полностью намерен перегружать данные и использование за пределами того, что может обрабатывать моя учетная запись хостинга, поэтому я решил - хотя было бы очень легко построить WP, чтобы попробовать работать из BackPress в качестве основы и выстроить только то, что мне нужно для моих конкретных случаев использования.
Таким образом, я смог сократить свою основную среду от сотен PHP-файлов в WP до тех пор, пока мне не понадобится двадцать или около того, хотя я все еще могу использовать все db, HTTP, user-management, форматирование , и функции cron, которые мне нравятся в WordPress.
Проблема заключается в том, что ее большая работа, и я никогда не буду доверять своей хитрости для чего-либо, кроме моего личного использования. Если вы хотите использовать полную среду WP, возьмите ее как есть. Это так хорошо, как благодаря сотням разработчиков, которые его настраивают в течение нескольких лет. Как и все, что здесь сказано, вы получите гораздо больше, найдя лучший план хостинга и исследуя методы кеширования, чем вы, вероятно, получите, взломав ядро.
Да, WordPress сначала загружает все, а затем делает то, что мы просим. Я могу где-то вспомнить, что мы можем создать виртуальный пул в ОЗУ, где мы можем помещать файлы. У меня возникла идея поместить весь WordPress в память (<10MB) & то мы сможем сэкономить много ввода-вывода, которое в одиночку должно дать ускорение скорости. Но у меня никогда не было возможности попробовать это, и, кроме того, я не очень разбираюсь в этом. Но стоит попробовать.
несколько основных предложений:
- w3 общий кэш-модуль для кэширования.
- установить и активировать memcache, а также включить из общих настроек кэша w3 (кеш-код кода также является хорошим вариантом, но он не подходит для плагина общего кэша w3)
- минимизировать запросы к прямым ссылкам в файлах тем.
- Отключите все дополнительные неиспользуемые плагины и удалите их.
- оптимизировать базу данных.
Я запускаю хорошо известный сайт Wordpress с огромным трафиком ежедневно .. im not on dedicated even, отлично подходит для меня :)