- Александр: Папка с последним вордпрессом весит ~12Мб....
- Виталя: "Сам php-код, js, css занимает какие-то мегабайты." - прям таки МЕГАБАЙТЫ )))))...
- Zver: Доброго времени суток. Подскажите как сделать BuddyPress на своей теме или например шорткодом хотябы...
- саша: У меня не работает ! когда нажимаю "подарки" там просто картинки и все что делать ?...
- Дмитрий: использую WP 3.3.1., пытался установить в поддерикторию, как ты описывал віше, но при активации плаг...
- ashok: Thank u for ur reply...
- slaFFik: FOL doesn't have a widget (yet), that displays a list of avatars of on-line friends. Perhaps in next...
- ashok: Sorry for that, in Sidebar Widjet it is showing Two Options: Recently Actives and Online Friends...
- slaFFik: Навороченность я оцениваю по времени, вбуханного в плагин. А мое время давно уже не дешевое. Тем ...
- slaFFik: What do you mean about "default results"? Don't understand what do you want....
Облегчаем жизнь серверу и ускоряем WordPress сайт
Я думаю, вы заметили, что я уделяю достаточно много внимания оптимизации скорости загрузки сайта. Мне интересна эта тема, потому что рано или поздно любой серьезный проект сталкивается с проблемой перегрузки сервера активностью посетителей.
Ранее я рассматривал техники полного кеширования сайта, настройку собственного сервера (часть 1, часть 2, часть 3), использование YSlow для ускорения сайта. Но это еще не все! Я также применял технику спрайтов (и не только) на своем сайте и включал zlib сжатие. Как видите, много всего я перепробовал и рассказал вам. Но и это не все…
Сегодня я нашел интересный плагин, который не претендует на уникальность – существует он достаточно давно, но просто он не так сильно распиарен, как Super Cache. Да, это плагин кеширования, и называется он DB Cache Reloaded. Оригинал этого плагина () перестал поддерживаться и обновляться автором, потому Daniel Frużyński создал версию Reloaded, которая рассчитана для WordPress 2.8.x-2.9.x. К сожалению, для WPMU+BP плагин не предназначен (я проверял – чуть не убил demo.сайт).
Итак, в чем особенность DB Cache Reloaded? Он кеширует, но не всю страницу – а лишь запросы к базе данных. Этим он экономит место на вашем диске и меньше нагружает винчестеры хостера. Я не буду вдаваться в технические подробности его работы (большинству это не нужно), кому будет интересно, тот прочитает обо всем . Просто скажу реальные результаты его работы.
Главная страница моего сайта очень нагружена – я отображаю 61 запись на ней (когда посчитал – был в шоке!), не считая блока комментариев и популярных записей в сайдбаре. Итого выходило на главной 129 запросов к базе данных и почти 35 мегабайт php памяти. Многовато, не так ли? И это при том, что я не использовал ни одного плагина кеширования!
После активации плагина DB Cache Reloaded и настройке его на соответствующей странице (я выставил жизнь кеша в течение 60 минут) вот мои новые результаты:
Сейчас: 23 запроса за 1.797 сек. | В кеше 106 запросов | Память – 27.07MB
Как видим, я значительно облегчил жизнь сервера, делая меньше запросов в базу примерно в 5 раз. Конечно же, это повлияло на скорость загрузки – на мой взгляд, увеличение заметно и невооруженным взглядом.
На данный момент 75 комментариев ↓
9 января 2010 в 9:32
А с MU что делать, есть ли какой нибудь плагин?
9 января 2010 в 10:51
slaFFik,
а почему не отрабатывается кеширование на стороне php хостера?.. ведь если бы установленный eaccelerator выполнял бы свои функции, то потребление памяти было бы меньше на 40%..
А вообще свой сервер лучше еще по одной причине – хостер грузит все модули php которые используют пользователи, а конкретному проекту на WordPress процентов 20 этих модулей не нужно..
Кстати – могу предоставить местечко на своем сервере… для тестов производительности при максимальной оптимизации основы.. ну эт если будет желание
totaliz,
для MU можно использовать WP Super Cache, но осторожно :) но самое главное – любой серьезный проект на WP MU – это 100% отказ от услуг хостера с виртуальными серверами…
9 января 2010 в 13:50
– это 100% отказ от услуг хостера с виртуальными серверами…
Вот эту фразу не совсем понял, кто от чего должен отказаться, а на чем такой проект планировать, если не трудно, плиз
9 января 2010 в 14:59
Любой серьезный проект (хотя бы несколько 1000 пользователей, из них несколько сотен активных – это уже серьезность) – это ОЧЕНЬ большое количество потребляемой памяти (шире – ресурсов)!
Никакой виртуальный хостинг не даст это большое количество.. можно было бы снизить потребление некоторыми оптимизациями, но вот виртуальный хостинг это “как есть”..
где то так…
Но лучше наверное не в этой теме об этом… ИМХО
9 января 2010 в 15:49
Александр, а какой примерно сервер (по параметрам) нужен, чтобы держать “хотя бы несколько 1000 пользователей”?
9 января 2010 в 19:44
“А с MU что делать, есть ли какой нибудь плагин?” Поддерживаю вопрос
9 января 2010 в 20:09
@wcp:
Я подумаю, можно ли что сделать с этим плагином.
10 января 2010 в 1:55
slaFFik если честно, очень бы хотелось увидеть статью по правильной настройке Super Cache (думаю это многим будет интересно), а также по разграничению прав на директории buddypress – проще говоря на какие папки нужно ставить 777, а на какие ни в коем случае нельзя ставить 777 :)
11 января 2010 в 20:29
Что подразумевает под собой виртуальный сервер. Это технологии openvz, xen… Технология Xen лучше, не буду все описывать, кому интересно, почитайте документацию, просто разница, openvz юзает общее ядро всей системы, xen – для каждой виртуалки свое ядро, на реальном железе, ну навскидку, раза в три быстрее работает, то есть для wpmu+buddypress нужен не менее 1 GB оперативки, плагины кеширования… тратится время и ресурсы на первое создание кешированной страницы, очень трудно словить оптимальное время, при достижении определенного предела, когда много кешированных страниц, тоже начинаются сложности, DB Cache Reloaded пробовал, не работает, подтверждаю))я вот сам сижу и думаю, а что же мы хотели, естественно, большой проект, много ресурсов))
11 января 2010 в 22:39
Потестите WP Super Cache Plus, на мой взгляд пока не обнаруживал траблы, автор утверждает, что он поддерживает eaccelerator, но я так и не разобрался как, мне доступно диск, memcached и memcached alt, у меня лучший результат показывает memcached alt, по скорости генерации страницы
11 января 2010 в 23:57
Татьяна,
если все оптимизировать.. то 1x3Ghz, 1Gb RAM вполне.. для совсем комфортной работы – 2Gb или сразу 4Gb (на перспективу)
Игорь
не заметил каких либо больших затрат по ресурсам при использовании WP Super Cache, хотя смотрел это на отдельном сервере (не виртуальный, не VDS и прочее)
По поддержке WPSC eaccelerator.. не знаю.. почему они должны друг друга поддерживать?.. один файлики текстовые генерит, а другой запросы кэширует…
12 января 2010 в 0:16
Александр, мне сложно объяснить, я не прогер, я все делаю только – сделал посмотрел, сужу только визуально, первый раз захожу на страницу – долго, смотрю время генерации, второй раз – очень быстро). Вообщем я остался на старой конфигурации научил nginx видеть super cache, super cache кеширует при помощи memcached alt, может я не прав, но тогда зачем для вордпресса всякие клиенты для eaccelerator написали, вот если объясните, буду признателен
12 января 2010 в 0:18
Да, насчет временных затрат, все зависит от количества посетителей… в данный момент подключившихся к серверу
12 января 2010 в 9:30
Игорь,
генерация первый раз занимает достаточное время.. но при этом потребление ресурсов копеечное :)
А вообще – WPSC надо аккуратно использовать на WP MU.. поддержка то есть.. но “как есть”
12 января 2010 в 15:08
Александр по поводу вашего ответа Татьяне “если все оптимизировать.. то 1×3Ghz, 1Gb RAM вполне.. для совсем комфортной работы – 2Gb или сразу 4Gb (на перспективу)”
это на несколько тысяч одновременно, на несколько тыс, просто “регулярно активных” юзеров или вообще на несколько тыс в сутки? XD извините за нубский вопрос