Рефакторинг 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

Вы можете видеть, что загрузка кода ускоряется массово, а код также занимает меньше места в памяти (вероятно, потому, что мы имеем дело только с кодами операций, а не с исходным исходным кодом). Однако потребление памяти довольно велико.

61 голос | спросил Roman Zenka 25 FebruaryEurope/MoscowbFri, 25 Feb 2011 22:15:27 +0300000000pmFri, 25 Feb 2011 22:15:27 +030011 2011, 22:15:27

8 ответов


25

Не стоит беспокоиться. WordPress не ест много памяти, потому что. Он ест много памяти, потому что у него много функций под капотом.

Гораздо проще и эффективнее кэшировать результаты (сгенерированные страницы) с помощью статического кеш-плагина и обслуживать их. Таким образом, большинство посетителей даже не попадет в сам WP.

ответил Rarst 25 FebruaryEurope/MoscowbFri, 25 Feb 2011 22:21:29 +0300000000pmFri, 25 Feb 2011 22:21:29 +030011 2011, 22:21:29
23
  

И вот почему я думаю, что WordPress   в серьезной необходимости переписать. Ты можешь   больше не обвиняют в потреблении памяти   от явной сложности того, что он делает.   Это просто неправильно.

Какой наивный вывод. Прочитайте Вещи, которые вы не должны делать, часть I .

Спасибо за графики использования памяти.

Много позже отредактируйте: Autommatic выпустила библиотеку под названием префикс , которая кажется делать то, о чем вы просите: загрузка кода WordPress в ОЗУ только один раз.

ответил scribu 27 FebruaryEurope/MoscowbSun, 27 Feb 2011 16:38:56 +0300000000pmSun, 27 Feb 2011 16:38:56 +030011 2011, 16:38:56
17

Начиная с WordPress 3.2, PHP 5.2 будет минимальным требованием. Я думаю, что под нашими поясами бит ядра может начать реструктурироваться и использовать классы с автоматической загрузкой. Это позволило бы избежать загрузки некоторых фрагментов кода, если они не были на самом деле . Например, если в представлении страницы не было никаких вложений или галерей, мы могли бы избежать загрузки большого количества медиа-кода.

Однако, даже если они решат пойти по этому маршруту, я ожидаю, что это будет медленная эволюция (как и большинство других изменений под капотом, которые произошли). Это потребует перетасовки вокруг места большого количества файлов и кода, которые могли бы сломаться назад для некоторых плагинов.

Часть проблемы (если ее действительно можно назвать) заключается в том, что без такой условной загрузки базовая инфраструктура не может заранее знать, какие функции ей понадобятся или не нужны для создания представления содержимого , Поэтому нужно загружать множество функций на всякий случай .

ответил Dougal Campbell 26 FebruaryEurope/MoscowbSat, 26 Feb 2011 00:09:28 +0300000000amSat, 26 Feb 2011 00:09:28 +030011 2011, 00:09:28
16
  

Как мы можем заставить Wordpress инициализировать   его окружение в памяти только один раз,   и затем повторно использовать его много раз для каждого   хит?

Это называется кодовым кэшированием.

http://en.wikipedia.org/wiki/PHP_accelerator

ответил Otto 28 FebruaryEurope/MoscowbMon, 28 Feb 2011 03:45:12 +0300000000amMon, 28 Feb 2011 03:45:12 +030011 2011, 03:45:12
5

вам, вероятно, не удастся значительно сократить использование барабанов. Но если вы используете mod_php, вы можете вместо этого перейти на mod_fcgid.

в то время как mod_php немного медленнее, он загружает php, даже когда это не нужно, например, показ изображений, статических файлов или даже кеширование. Если у вас много запросов, это много бара.

Использование fcgid значительно уменьшит это.

также, используя статический кеш (например, w3total cache), вы избежите вызова php вообще , что является действительно большим преимуществом: меньшее использование ram, меньше db-соединений.

ответил boyska 7 FebruaryEurope/MoscowbTue, 07 Feb 2012 04:02:10 +0400000000amTue, 07 Feb 2012 04:02:10 +040012 2012, 04:02:10
4

га. Сейчас я работаю над веб-приложением, так что я полностью намерен перегружать данные и использование за пределами того, что может обрабатывать моя учетная запись хостинга, поэтому я решил - хотя было бы очень легко построить WP, чтобы попробовать работать из BackPress в качестве основы и выстроить только то, что мне нужно для моих конкретных случаев использования.

Таким образом, я смог сократить свою основную среду от сотен PHP-файлов в WP до тех пор, пока мне не понадобится двадцать или около того, хотя я все еще могу использовать все db, HTTP, user-management, форматирование , и функции cron, которые мне нравятся в WordPress.

Проблема заключается в том, что ее большая работа, и я никогда не буду доверять своей хитрости для чего-либо, кроме моего личного использования. Если вы хотите использовать полную среду WP, возьмите ее как есть. Это так хорошо, как благодаря сотням разработчиков, которые его настраивают в течение нескольких лет. Как и все, что здесь сказано, вы получите гораздо больше, найдя лучший план хостинга и исследуя методы кеширования, чем вы, вероятно, получите, взломав ядро.

ответил goldenapples 3 MaramThu, 03 Mar 2011 01:10:01 +03002011-03-03T01:10:01+03:0001 2011, 01:10:01
3

Да, WordPress сначала загружает все, а затем делает то, что мы просим. Я могу где-то вспомнить, что мы можем создать виртуальный пул в ОЗУ, где мы можем помещать файлы. У меня возникла идея поместить весь WordPress в память (<10MB) & то мы сможем сэкономить много ввода-вывода, которое в одиночку должно дать ускорение скорости. Но у меня никогда не было возможности попробовать это, и, кроме того, я не очень разбираюсь в этом. Но стоит попробовать.

ответил Ashfame 25 FebruaryEurope/MoscowbFri, 25 Feb 2011 22:35:51 +0300000000pmFri, 25 Feb 2011 22:35:51 +030011 2011, 22:35:51
3

несколько основных предложений:

  1. w3 общий кэш-модуль для кэширования.
  2. установить и активировать memcache, а также включить из общих настроек кэша w3 (кеш-код кода также является хорошим вариантом, но он не подходит для плагина общего кэша w3)
  3. минимизировать запросы к прямым ссылкам в файлах тем.
  4. Отключите все дополнительные неиспользуемые плагины и удалите их.
  5. оптимизировать базу данных.

Я запускаю хорошо известный сайт Wordpress с огромным трафиком ежедневно .. im not on dedicated even, отлично подходит для меня :)

ответил Ayaz Malik 6 MarpmSun, 06 Mar 2011 22:59:19 +03002011-03-06T22:59:19+03:0010 2011, 22:59:19

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132