Производительность: BuddyPress – цифры, советы. Часть 2

Сегодня я напишу о том опыте, который у меня появился при работе с WordPress MU и BuddyPress.

Для начала напишу краткое резюме. Мы знаем, на что способен BP, многие из нас скачали, установили и настраивают его под себя. Сама по себе платформа очень замечательно выглядит в плане функциональности и потенциала, но в основном этот функционал связан с WordPress, на основе которого и работает все. Мне нравится возможность взаимодействия с пользователями, достаточная гибкость (при условии знания php-кода), но большим минусом является тяжелая настройка производительности.

Вот о ней и поговорим в очередной раз.

Вы установили WordPress MU – прекрасно, будьте готовы к тому, что у вас размер php-памяти уменьшился на добрых два десятка (ведь никто не ставит его пустым – всегда куча плагинов сверху, многие идут в папку /mu-plugins/). На большинстве хостинг-планах размер памяти, отведенный для обработки ограничен 32 метрами (как выяснилось). Причем для поддоменов иногда бывает еще меньше. При установке BuddyPress увеличивается нагрузка на сервер, так как все его файлы загружаются в память при каждом посещении человеком вашего сайта. В распакованном виде “чистый” BuddyPress вес полтора мегабайта. Если поставили набор плагинов от Nicola Grecko – то это дополнительные почти 2 Мб.

Вот вам данные для примера, взятые с моего демо-сайта для BuddyPress.

При нулевом WPMU потребление – 17,8 Мб. При подключении BuddyPress+ – 20 Мб (данные для WPMU 2.7 и беты BuddyPress. На данный момент числа в полтора раза больше!).

Я взял за основу то, что пользователи чаще всего будут посещать главную страницу сайта, свой профиль, свой блог, страницу групп и блогов и форум.

На сайте не активировано ни одного плагина WordPress (вообще). Делал я так специально для репрезентативности. Но установлена моя версия BuddyPress и весь набор плагинов от Nicola Grecko. При загрузке главной страницы потребление памяти – 20 Мб (это при пустом WordPress MU!) и 99 запросов в базу данных. Какие виджеты создают их – вы прекрасно можете увидеть.

При первой за сессию загрузке страницы профиля количество запросов – около 300!!! Все последующие разы – чуть больше 100 (103-108). Такое большое первое значение обусловлено работой встроенного кеширования запросов в БД. Для вас это означает вот что – большое количество уников – будьте готовы к большим требованиям производительности. А памяти php при первом разе – 21 метр, при последующих – около 20.

При посещении своего блога, отличного от главного, показатели примерно одинаковы для всех пользователей, разница возникает лишь из-за объема записей на главной (чем больше записей – тем медленнее грузит и больше запросов), память в районе 20-21 Мб.

При посещении страницы группы (своей или чужой- разницы практически нет) количество запосов к БД – 145-150 и память чуть больше 20 Мб. Это при условии настроенных виджетов для групп в плагинах BPDEV. Данные не кешируются, поэтому такое количество будет каждый раз. Кстати, при посещении форума группы ситуация примерно такая же, только базе легче чуток (на 20 запросов).

Как видим, ситуация для одного человека на сайте – терпимая. А что будет при 150 одновременно гуляющих по страницам?

Во-первых, вы столкнетесь рано или поздно с проблемой php memory limit. Мне пришлось на одном из сайтов клиентов увеличивать это значение до 64 мегабайт лишь для того, чтобы я мог активировать обычные плагины WordPress сверх уже настроенного BuddyPress. Сделал я это прописав код в файле .htaccess (в самом начале файла):

php_value memory_limit 64M

Это сняло напряжение и ускорило работу сайта. Это может не всегда работать, но поставить такое нужно обязательно – иначе при более менее серьезном проекте вы заколупаете ваш саппорт хостинга. Кстати, не помешает сначала спросить у них, сколько у вас выделение памяти для php-скриптов, а уж потом прописывать этот код.

И кстати о хостинге. Если хотите держать хотя бы тысячу посетителей – забудьте о виртуальном хостинге. На первом этапе – при настройки и первичном завлечении его хватит, но потом начнется страх один по соотношению доступности сайта к его недоступности. Я советую минимум (виртуальный) выделенный сервер – вот тогда уже можно заниматься чем-то серьезным. У кого есть собственный сервак – проблем вообще не будет. Еще необходимым условием является собственный веб-сервер, что означает, что вы можете редактировать файлы httpd.conf и php.ini (желательно). Чем больше возможостей по настройке своего сервера – тем лучше для вашего сайта.

Теперь о кешировании. В самом BuddyPress оно присутствует, но работает только для активности пользователя и его друзей (то есть кешируется лишь его активность и активность друзей на сайте). Все остальное генерируется каждый раз при запросе. В своем предыдущем посте, посвященном производительности BuddyPress, я писал о том, что надо использовать для ускорения работы сайта. Так теперь я говорю абсолютно серьезно – без этого у вас ничего стоящего не получится!

Когда я устанавливаю связку WPMU+BuddyPress я предлагаю клиентам установить плагины, которые на мой взгляд необходимы сайту. Я обязательно ставлю плагин кеширования, который настраиваю специально под работу с BuddyPress – он действительно облегчает производительность сайта в целом [Я проверял]

Что помнил – написал, на пока вроде все. Задавайте вопросы, вдруг что – по возможности отвечу.

комментариев 25

  1. BuddyPress now has object caching which reduces the load and query count by 3x:
    http://trac.buddypress.org/changeset/1238

  2. Oh, Andy, glad to see you here on my site!
    Really cool modification! When I installed to somebody BuddyPress I was using WP-cache 0.9 adapted by some options to it. But triple reducing is really great.
    I think, some changes will be made to my buddypress archive.

  3. максим:

    прочитал, правда не догнал зачем, я там в настройках прописал память php без лимита, сервак появился, а вот людей реальных собрать и активировать их на работу сайта -работа в этом направлении подходит к концу

  4. Прожорливый вордпресс, как скотина – это можно и не обсуждать:)
    Но, к сожалению, только так можно достигнуть гибкости и универсальности…
    Свои движки работают примерно в 100, а то и в 1000 раз быстрее, но затраты на их создание часто не окупаются.

  5. post:

    wow, slaFFik, какие гости на сайте…

  6. На своем сайте я рад всем!

  7. Ммм… “какие гости”… Меня никто особо знать не должен :)

  8. Ну почему же, твой плагин выложен у меня :) Да и могли видеть на сайте bpdev или еще где… Да и просто раньше много комментариев от тебя было…

  9. Felix:

    А что насчёт плагина Супер кеш? Для МУ он существует?

  10. У меня с Супер кеша BuddyPress глючить начал…

  11. Конечно существует, только его надо устанавливать так, как описано в инструкции (в самом архиве плагина – readme), иначе будут проблемы. А глючит он, если не настроен, там надо вручную прописывать настройки для некоторых страниц.

  12. slaFFik! Я читал… что структура BuddyPress изменилась… когда ждать новостей от тебя по этому поводу…

  13. у меня сейчас аврал – сначала сгорела матка (всю прошлую неделю занимался ею), потом проблемы с ethernet, потом 5 курсовых работ за 5 дня надо сделать :) Вот сейчас ими и занимаюсь…
    Простите, но новости будут только в пятницу – когда я сдам в универе (надеюсь) все, что от меня потребуется.
    Ждите!

  14. Alex:

    Плагин Hiper Cash 2.0 намного стабильнее Super Cash`а и более гибко настраивается. С MUWP, не конфликтует… по крайней мере у меня работает без косяков… :)

  15. shirs:

    Плагин Hiper Cash 2.0 намного стабильнее Super Cash

    а памяти сколько кушает?

  16. Alex:

    To: Shirs. насколько знаю – HC не создает структуру папок на диске. Складывает файлы .dat в свою папку с кэшем, при этом можно задавать время жизни, а после этого полностью очищать папку. Точно не скажу сколько памяти кушает, потому как ресурс пока не на полную катушку работает – нагрузки не очень большие , по показаниям тюнера – за 3,2 сек выдал на гора 170 кв. Тут большое значение играет хостер – его производительность.

  17. Лично я считаю, что думать о кеше для вас пока нет смысла. У меня до 500-600 посещений в день бывает – кеш мне не нужен, сайт нормально все перерабатывает. Его надо ставить только в том случает, если чувствуется, что сайт не тянет. Только тогда будет ощутимо увеличение скорости. До того момента нет смысла занимать память и свой мозг.
    Повторюсь – это мое личное мнение. Но с Alex я согласен по поводу важности производительности хостера.

  18. Никита:

    Ну и что, результат есть ?

  19. Jettochkin:

    Сервер на 4Gb RAM, 2 проца двухядерных.. без кеша жестко ;)

  20. Андрей:

    Как на сегодняшний день обстоят дела с производительностью? Планирую новый проект и интересна связка WP + BP . Только вот по нагрузке на сегодняшний день актуальной информации нету

    • Ну почему же, есть. Я писал на этом же сайте. И в последней версии тоже были улучшения. В целом стало гораздо лучше. К примеру, CosyDale крутится вообще без каких-либо кеширующих плагинов.

  21. Для какой цели плодить соцсети?

    • У всех разные цели. Кому-то может быть удобнее для жильцов дома или маленького городка/поселка сделать маленькую сеть, а не группу в FB или VK.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *