На каждом шагу можно услышать о том, что последние версии WordPress потребляют много памяти. Безумно много памяти. Что от этого бывают проблемы с хостерами при высокой посещаемости. Что из-за этого Вордпресс не подходит для создания сателлитов. В общем, много непонятных слов.
Начнем с азов. Вы наверняка знаете какие-то базовые параметры вашего домашнего компьютера. Например, у него может быть 2 гигабайта оперативной памяти, процессор на 3 ГГц и жесткий диск (винчестер) на 500 ГБайт. Размещая ваш сайт в Интернете, вы используете самый обычный компьютер (но принадлежащий вашей хостинг-компании). Да, он наверняка внешне не похож на ваш домашний компьютер; наверняка он вмонтирован в стойку, наверняка в нем не один процессор и не один жесткий диск, и памяти намного больше. Но в случае с вашим домашним компьютером – он принадлежит вам и только вам, а в случае с компьютером хостера – на одном сервере может быть более тысячи сайтов. Итак, какие могут быть причины отключения сайта хостером (как правило, сопровождаются предложением перевестись на более дорогой тариф)?
Ваш сайт – чаще всего самая обычная программа. На домашнем компьютере, у вас, вероятно тоже есть программы: Micrsofot Word, OpenOffice Writer, Adobe Photoshop, NOD32, Firefox, Internet Explorer, Outlook Express. Возможно, программа вашего сайта написана на языке программирования PHP – например, в случае использования WordPress, Joomla, Drupal, ModX, TextPattern - это так и есть. Эта программа сама по себе не запускается – а запускается лишь когда пользователь входит к вам на сайт.
Мы продолжим аналогию с домашними программами: наверняка вам приходилось слышать “фотошоп тормозит, купи еще планку памяти” или что-то вроде того. Или: “здесь мало памяти, сначала закрой все другие программы”. Здесь, в мире Интернет, все то же самое. Только программы работают очень короткое время (как правило, не больше 10 секунд подряд: ведь вы же не будете дожидаться загрузки сайта несколько минут, если вообще ничего не видите?). Один сайт потребляет больше памяти, чем другой – это нормально. Причем память расходуется на все обращения к сайту: загрузка страниц сайта, картинок, стилей, скриптов.
Картинки, стили и скрипты – это “статическое содержимое”. Оно не изменяется с течением времени (на самой картинке же посетитель сайта не может оставить комментарий, да?), и на такие обращения нужно меньше всего ресурсов (процессорное время практически не используется, памяти нужно минимальное количество). Впрочем, если к вам на сайт с исключительно статическими материалами будет заходить 100 тысяч человек в сутки, нагрузку он все равно будет создавать приличную. Но в нашем случае основная проблема – это “динамическое содержимое”.
Скажем, на одно отображение страницы WordPress 2.8 тратит около 19 Мб памяти и 1 секунду времени. Это значит, что в течение 1 секунды, всем остальным клиентам вашего хостинга недоступно примерно 25 мегабайт памяти. Предположим, что у вас – 100 посетителей в сутки и в среднем они осуществляют 3 просмтра страницы. Значит, ваш сайт расходует где-то 300*25 Мбайт памяти в течение 300 секунд. В масштабах целых суток – все нормально.
Но предположим, что у сайта начинает расти посещаемость (до 150 человек в сутки), или же вы установили какой-нибудь супер-пупер новый плагин, и потребление памяти WordPress возросло до 30 Мбайт. Таким образом, потребление ресурсов хостера выросло примерно на 50%. Если хостер сочтет, что вы потребляете слишком много памяти и процессорного времени за те деньги, которые вы ему платите – вам будет отправлено предупреждение о возможном отключении сайта и предложение сменить тарифный план.
На основании каких критериев хостер определяет такую ситуацию – довольно большая загадка, критерии у всех свои. Я для маленького стороннего проекта использую хостинг mirex.su, появившийся относительно недавно – там таких проблем пока нет, т.к. очевидно, серверы еще не работают на полную мощность. Например, я попросил разрешения увеличить объем памяти, доступный WordPress – мне ответили согласием. У многих крупных хостеров такое невозможно в принципе. И у большинства крупных – невозможно постфактум (“три дня назад поменял, потом спросил – можно ли”).
Но это все теория… А что же делать, если хостер информирует своего клиента об отключении сайта за повышенное потребление ресурсов?
Для начала (как обычно и бывает с компьютерами), нужно выяснить, что случилось недавно. Возможно, у сайта резко выросла популярность (скажем, ссылка на него появилась на заглавной habrahabr.ru, в англоязычном интернете такое называлось “эффект Slashdot”). Возможно, сайт был недавно обновлен (установлена свежая версия WordPress, Joomla, Bitrix, или что там у вас на сайте?). Возможно, вы добавили новую страницу или установили новый плагин?.. Возможно, ваш прайс-лист увеличился вдвое?
Часто проблему можно решить путем включения кэширования. Например, для WordPress это может быть плагин WP-SuperCache. В ModX на нужных страницах можно поставить флажок “кэшируемый документ”. В Drupal это делается в меню “Настройка сайта –> Производительность”. Для Joomla можно скачать PageCache.
Если простым кэшированием не обошлось – нужен взгляд профессионала. Необходимо найти “плохой” плагин или модуль, и обновить, починить или заменить его. Навскидку – могу порекомендовать отключить модули статистики и использовать вместо них счетчик LiveInternet или Google Analytics. Полная оптимизация сайта может занять огромное количество времени (и денег), так что устраняйте проблемы по мере их возникновения
WordPress Mu 2.8.1 и BuddyPress, ускоряемся
В нашей инсталляции WordPress Mu, достаточно большой (8-10 мб памяти) объем ресурсов отжирает плагин социальной сети BuddyPress. Что самое неприятное, при глобальной его активации на всем сайте, WordPress Mu загружает его даже в случае поиска внешних ссылок на этот блог в админке.
Как известно, ресурсы хостеров не резиновые. Даже если это dedicated сервер, и ты сам себе хостер. Давайте подумаем, что с этим можно сделать.
Все глобальные плагины загружаются почему-то из файла с совершенно неговорящим названием, wp-setttings.php. Поиск внешних ссылок и другие AJAX-запросы можно отличить по наличию в URL подстроки index-extra.php. Возможно, это не лучший путь, но я пошел такой дорожкой.
Для начала, в файле admin/index-extra.php зададим дефайн.
Код: Виділити все
@define('WP_AJAX', 1);Код: Виділити все
sort( $mu_plugins );
foreach( $mu_plugins as $mu_plugin ) {
include_once( WPMU_PLUGIN_DIR . '/' . $mu_plugin );
}Код: Виділити все
sort( $mu_plugins );
foreach( $mu_plugins as $mu_plugin ) {
if (!defined('WP_AJAX')) { include_once( WPMU_PLUGIN_DIR . '/' . $mu_plugin ); }
}На первый взгляд, мы ничего особенного не сделали. Однако, если каждый запрос выполняется 0.7 секунды (у нас так), то 1.5 секунды на сервере будет на 20 Мб свободной памяти больше. А полторы секунды и 20 мегабайт памяти достаточно, чтобы отдать клиентам половину некэшированной страницы. И этой экономии мы добиваемся всякий раз, входя в Dashboard блога. К слову сказать, на нашем маленьком сайте эти запросы выполняются от 100 до 600 раз в сутки, а это уже дает нам ресурсы минимум на 50 лишних клиентских запросов.
Уменьшаем использование памяти WordPress: оптимизация расхода памяти
Если вдумчиво изучить содержание памяти запущенного WordPress, можно заметить, что значительную часть занимают переводы. Это число может достигать четверти или даже трети всей памяти движка. Чем это чревато, я уже писал ранее в статье “О потреблении памяти. Вордпресс. Хостеры”. Бороться со “слишком жирными” переводами можно разными способами:
- •сократить количество закэшированных переводов;
•оптимизировать структуру кэша переводов в памяти;
•избавиться от перевода при помощи gettext совсем.
Внимательно присмотревшись к составу .po файла с переводом, можно заметить, что значительная (а в случае с базовым WordPress – большая) часть переводов – это интерфейс панели управления WordPress (админки).
В файле конфигурации WordPress присутствуют строки (wp-config.php):
Код: Виділити все
/**
Язык WordPress. Если не указан никакой, то будет английский!
По умолчанию для локализации предлагается такой вариант: define ('WPLANG', 'ru_RU');
но вы можете существенно снизить нагрузку на ваш блог, раскомментировав строку: if (strpos($_SERVER['REQUEST_URI'], 'wp-admin')) define ('WPLANG', 'ru_RU'); else define ('WPLANG', 'ru_RU_lite');
и закомментировав строку define ('WPLANG', 'ru_RU');
тогда в админке вы будете использовать полный файл перевода, а для лицевой части блога облегченный файл перевода.
в среднем это снижает потребление памяти на 3 мегабайта и ускоряется генерация страницы. Также может понадобиться для тех плагинов,
которые что-либо выводят на лицевую часть блога создать файлы с переводами по технологии: скопировать файл, например wptuner-ru_RU.mo в wptuner-ru_RU_lite.mo
тоже самое нужно сделать и если ваша Тема локализована через внешний файл перевода. Более подробно на http://lecactus.ru/2008/11/15/3110/
/
define ('WPLANG', 'ru_RU');
// if (strpos($_SERVER['REQUEST_URI'], 'wp-admin')) define ('WPLANG', 'ru_RU'); else define ('WPLANG', 'ru_RU_lite');Код: Виділити все
// define ('WPLANG', 'ru_RU');
if (strpos($_SERVER['REQUEST_URI'], 'wp-admin')) define ('WPLANG', 'ru_RU'); else define ('WPLANG', 'ru_RU_lite');Оптимизировать расход памяти можно и при помощи модификации исходников WordPress. У меня потребление памяти переводами понижается примерно на 1/6. Делается это следующим образом:
Откроем на редактирование файл wp-includes/pomo/entry.php. Закомментируем в нем такие строчки:
Код: Виділити все
var $translations = array();
/
var $translator_comments = '';
var $extracted_comments = '';
var $references = array();
var $flags = array();
/Код: Виділити все
if (!is_array($this->translations)) $this->translations = array();
/
if (!is_array($this->references)) $this->references = array();
if (!is_array($this->flags)) $this->flags = array();
/Код: Виділити все
if (!is_array($this->translations)) $this->translations = array();Насколько я могу судить, это совершенно безопасное изменение – я не нашел следов использования флагов записи, и уж тем более использования комментариев переводчика.
В результате вышеописанных манипуляций, получилось 2.5 Мбайт экономии на небольшой социальной сети на основе BuddyPress и WordPress MU.
Быстрый перевод блога – безо всякого POEdit!
Плагин для перевода WordPress “на лету”. http://www.code-styling.de/english/deve ... ization-en
Работает только от версии 2.5 и выше
Источник: http://cms.baron.su