-
стеллажи для склада
- Двери подъездные с домофоном. Обзор подъездных домофонов.
- Одноразовая посуда и упаковка - одноразовая посуда. Одноразовые изделия.
Сегодня я напишу о том опыте, который у меня появился при работе с 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 – он действительно облегчает производительность сайта в целом [Я проверял]
Что помнил – написал, на пока вроде все. Задавайте вопросы, вдруг что – по возможности отвечу.
Понравился пост? Подпишись на
Получай всю интересную информацию первым.
![]()
RSS лента комментариев на эту запись ↔ TrackBack URL
22 марта 2009 в 18:09
BuddyPress now has object caching which reduces the load and query count by 3x:
23 марта 2009 в 8:41
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.
23 марта 2009 в 12:15
прочитал, правда не догнал зачем, я там в настройках прописал память php без лимита, сервак появился, а вот людей реальных собрать и активировать их на работу сайта -работа в этом направлении подходит к концу
26 марта 2009 в 15:00
Прожорливый вордпресс, как скотина – это можно и не обсуждать:)
Но, к сожалению, только так можно достигнуть гибкости и универсальности…
Свои движки работают примерно в 100, а то и в 1000 раз быстрее, но затраты на их создание часто не окупаются.
27 марта 2009 в 14:15
wow, slaFFik, какие гости на сайте…
27 марта 2009 в 15:13
На своем сайте я рад всем!
27 марта 2009 в 17:50
Ммм… “какие гости”… Меня никто особо знать не должен :)
27 марта 2009 в 18:54
Ну почему же, твой плагин выложен у меня :) Да и могли видеть на сайте bpdev или еще где… Да и просто раньше много комментариев от тебя было…
5 апреля 2009 в 8:04
А что насчёт плагина Супер кеш? Для МУ он существует?
5 апреля 2009 в 17:12
У меня с Супер кеша BuddyPress глючить начал…
6 апреля 2009 в 19:28
Конечно существует, только его надо устанавливать так, как описано в инструкции (в самом архиве плагина – readme), иначе будут проблемы. А глючит он, если не настроен, там надо вручную прописывать настройки для некоторых страниц.
6 апреля 2009 в 20:12
slaFFik! Я читал… что структура BuddyPress изменилась… когда ждать новостей от тебя по этому поводу…
6 апреля 2009 в 21:37
у меня сейчас аврал – сначала сгорела матка (всю прошлую неделю занимался ею), потом проблемы с ethernet, потом 5 курсовых работ за 5 дня надо сделать :) Вот сейчас ими и занимаюсь…
Простите, но новости будут только в пятницу – когда я сдам в универе (надеюсь) все, что от меня потребуется.
Ждите!
12 июня 2009 в 20:29
Плагин Hiper Cash 2.0 намного стабильнее Super Cash`а и более гибко настраивается. С MUWP, не конфликтует… по крайней мере у меня работает без косяков… :)
12 июня 2009 в 22:05
а памяти сколько кушает?
13 июня 2009 в 13:58
To: Shirs. насколько знаю – HC не создает структуру папок на диске. Складывает файлы .dat в свою папку с кэшем, при этом можно задавать время жизни, а после этого полностью очищать папку. Точно не скажу сколько памяти кушает, потому как ресурс пока не на полную катушку работает – нагрузки не очень большие , по показаниям тюнера – за 3,2 сек выдал на гора 170 кв. Тут большое значение играет хостер – его производительность.
13 июня 2009 в 14:20
Лично я считаю, что думать о кеше для вас пока нет смысла. У меня до 500-600 посещений в день бывает – кеш мне не нужен, сайт нормально все перерабатывает. Его надо ставить только в том случает, если чувствуется, что сайт не тянет. Только тогда будет ощутимо увеличение скорости. До того момента нет смысла занимать память и свой мозг.
Повторюсь – это мое личное мнение. Но с Alex я согласен по поводу важности производительности хостера.
22 августа 2009 в 17:01
Ну и что, результат есть ?
30 апреля 2010 в 21:22
Впервые вижу сайт о паразитах)))
30 апреля 2010 в 21:30
Я сам впервые вижу )) Я решил оставить коммент – на память.
30 апреля 2010 в 19:50
Сервер на 4Gb RAM, 2 проца двухядерных.. без кеша жестко ;)