Comments 62
аккуратная работа с сущностью блоков на версиях до 6 включительно приводит к существенному ускорению работы
Забыл про блоки.
Не использовать php формат в блоках — это точно стоит отметить.
Что-то еще?
Не использовать php формат в блоках — это точно стоит отметить.
Что-то еще?
а можно поподробнее?
для начала нужно установить видимость блоков только на тех страницах, где они нужны, чтобы они не генерились, скажем в админке
А подробнее в общем-то здесь:
drupal.org/node/326504
Читайте drupal.org, там есть все ответы, правда по-ангийски :-(
А подробнее в общем-то здесь:
drupal.org/node/326504
Читайте drupal.org, там есть все ответы, правда по-ангийски :-(
Мораль есть, но куцая. Какой комплекс мер в итоге были предпринят кроме переезда и почему?
Знаете, у меня малопосещаемый сайт (около 300 уников в день).
После переезда были отключены все кэширующие модули, поскольку на том хостинге и так грамотно настроет nginx как кэширующий прокси-сервер.
Единственно что я оставил включенным, это оптимизацию css+javascript и emiimage чтобы уменьшить число обращений к серверу.
При такой нагрузке сайт прекрасно работает.
Думаю, кэширование стоит включать, когда число уникальных посетителей существенно превышает число страниц на сайте.
После переезда были отключены все кэширующие модули, поскольку на том хостинге и так грамотно настроет nginx как кэширующий прокси-сервер.
Единственно что я оставил включенным, это оптимизацию css+javascript и emiimage чтобы уменьшить число обращений к серверу.
При такой нагрузке сайт прекрасно работает.
Думаю, кэширование стоит включать, когда число уникальных посетителей существенно превышает число страниц на сайте.
Извините, но 300 уников в день это не нагрузка, это быдлохост.
Я знаю проекты по 80 000 просмотров на шареде и всё нормально.
Знаю и 160 000 просмотров на дедике х 500 онлайн, зареганые и анонимы по 50%.
Кеширование это стратегия и война.
И такой статьёй вы принесёте новичкам, а ведь именно они на это клюют, только проблемы и грабли.
Ждите апрельского кампа, будут пара докладов
Я знаю проекты по 80 000 просмотров на шареде и всё нормально.
Знаю и 160 000 просмотров на дедике х 500 онлайн, зареганые и анонимы по 50%.
Кеширование это стратегия и война.
И такой статьёй вы принесёте новичкам, а ведь именно они на это клюют, только проблемы и грабли.
Ждите апрельского кампа, будут пара докладов
я знаю, что это не нагрузка.
потому и пишу, что не стоит пытаться решать кэшированием то, что еще не доросло до кэширования.
Руцентр, вроде весь такой крутой, никакими усилиями не позволил добиться того, что сразу заработало в нормальном месте
потому и пишу, что не стоит пытаться решать кэшированием то, что еще не доросло до кэширования.
Руцентр, вроде весь такой крутой, никакими усилиями не позволил добиться того, что сразу заработало в нормальном месте
UFO just landed and posted this here
Я не хочу приводить в пример то место — я не ради рекламы это писал.
В нем нет ничего особенного.
По поводу руцентра. Тариф 301. Лимит памати 192 MB.
Процесс Апача, прогруженный всеми необходимыми модулями php для Друпала занимает около 45.
Крутимся, устанавливаем nginx по их инструкции. Но все равно остается не больше трех апачей на обслуживание клиентов. Про кэширующие в памяти модули тоже забываем.
В нем нет ничего особенного.
По поводу руцентра. Тариф 301. Лимит памати 192 MB.
Процесс Апача, прогруженный всеми необходимыми модулями php для Друпала занимает около 45.
Крутимся, устанавливаем nginx по их инструкции. Но все равно остается не больше трех апачей на обслуживание клиентов. Про кэширующие в памяти модули тоже забываем.
руцентр был крутым довольно долго, но примерно за месяц до нг основательно слился
Я ушел в офф-лайн. На все вопросы отвечу ночью
Кэширование — только один из аспектов оптимизации.
Устанавливать только те модули, в которых есть необходимость.
Отключить журналы (логи), если в них нет особой необходимости (в штатной ситуации редко нужны).
Не использовать PHP вставки в блоках, если нет крайней необходимости.
Использовать memcached (при помощи модуля memcache), если возможно.
Использовать PHP акселератор (я сейчас использую xcache), если возможно.
Ну и, конечно. не забывать про всё остальное — MySQL (или чем пользуетесь) тоже должен быть настроен как следует.
На shared я сайты давно не держу, правда, только на VDS/DS.
Устанавливать только те модули, в которых есть необходимость.
Отключить журналы (логи), если в них нет особой необходимости (в штатной ситуации редко нужны).
Не использовать PHP вставки в блоках, если нет крайней необходимости.
Использовать memcached (при помощи модуля memcache), если возможно.
Использовать PHP акселератор (я сейчас использую xcache), если возможно.
Ну и, конечно. не забывать про всё остальное — MySQL (или чем пользуетесь) тоже должен быть настроен как следует.
На shared я сайты давно не держу, правда, только на VDS/DS.
Я правда не понял эту фразу:
> сервер у нас нагружен, поскольку все время работает boost
Буст — это одно обращение к диску если все правильно настроено, и любой кеш на БД будет делать полюбому больше обращений. Поэтому любой БД кеш будет давать больше «нагрузки на хостинг» чем буст. А по факту идея буста в том чтобы веб-сервер напрямую отдавал готовенький ХТМЛ без обращения вообще к ПХП (ядру друпала). Таким образом освобождаются проц, память, БД (и как следствие диск) и всем лучше.
Но с бустом мне не удалось настроить желаемые заголовки expires, и в моем случае он все время скачивал ХТМЛ с сервера (не кешировался браузером), и похоже эту проблему мне еще предстоит решить.
> сервер у нас нагружен, поскольку все время работает boost
Буст — это одно обращение к диску если все правильно настроено, и любой кеш на БД будет делать полюбому больше обращений. Поэтому любой БД кеш будет давать больше «нагрузки на хостинг» чем буст. А по факту идея буста в том чтобы веб-сервер напрямую отдавал готовенький ХТМЛ без обращения вообще к ПХП (ядру друпала). Таким образом освобождаются проц, память, БД (и как следствие диск) и всем лучше.
Но с бустом мне не удалось настроить желаемые заголовки expires, и в моем случае он все время скачивал ХТМЛ с сервера (не кешировался браузером), и похоже эту проблему мне еще предстоит решить.
Да, и ссылку на блог я-бы убрал.
Зачем вам лишние минуса к топику или к карме? Тут так не принято :)
Зачем вам лишние минуса к топику или к карме? Тут так не принято :)
>Я правда не понял эту фразу:
> > сервер у нас нагружен, поскольку все время работает boost
Я имею в виду, что работает boost crawler.
Если страниц на сайте много, а пользователей относительно мало, но включая boost мы не уменьшаем нагрузку на хостинг, а, наоборот увеличиваем — генерация страниц по запросам паука и создает эту нагрузку.
> > сервер у нас нагружен, поскольку все время работает boost
Я имею в виду, что работает boost crawler.
Если страниц на сайте много, а пользователей относительно мало, но включая boost мы не уменьшаем нагрузку на хостинг, а, наоборот увеличиваем — генерация страниц по запросам паука и создает эту нагрузку.
Boost crawler не обязательно включать. Он нужен если вы хотите в фоне генерить кеш. Если его выключить, то кеш будет генериться на лету, то есть если есть закешированная версия страницы, то будет отдаваться она, если нет, то страница будет создана, закеширована и отдана юзеру.
я пробовал, показалось очень неэффективно.
страницы все равно устаревают.
То есть опять, чтобы от буста был толк, получается, что нужно, чтобу число посетителей в день было сильно выше, чем число страниц.
Хотя я не настаиваю, это мое личное мнение.
страницы все равно устаревают.
То есть опять, чтобы от буста был толк, получается, что нужно, чтобу число посетителей в день было сильно выше, чем число страниц.
Хотя я не настаиваю, это мое личное мнение.
Единственное, что я могу сказать: что-то криво у вас настроено. Буст без краулера позволяет держать нагрузку на несколько порядков превышающую ваши 300 уников в сутки.
У меня в нормальном месте и без буста прекрасно все работает.
Одна из мыслей статьи — что не надо использовать буст на 300 уников.
Потому что если у вас плохой хостинг, то он не спасет.
300 уников — это сайт, еще НЕ ДОРОСШИЙ до буста.
Одна из мыслей статьи — что не надо использовать буст на 300 уников.
Потому что если у вас плохой хостинг, то он не спасет.
300 уников — это сайт, еще НЕ ДОРОСШИЙ до буста.
Одна из мыслей статьи — что не надо использовать буст на 300 уников.
Потому что если у вас плохой хостинг, то он не спасет.
Плохая мысль. На «плохом» хостинге для сайта, основными посетителями которого являются анонимы, грамотно настроенный буст — это панацея, которая сильно снизит нагрузку на сервер.
Потому что если у вас плохой хостинг, то он не спасет.
Плохая мысль. На «плохом» хостинге для сайта, основными посетителями которого являются анонимы, грамотно настроенный буст — это панацея, которая сильно снизит нагрузку на сервер.
то, что кеш на диске быстрей и тратит меньше ресурсов — довольно популярное мнение, хотя на практике все мои тесты показали совершенно противоположный результат
UFO just landed and posted this here
К сожалению, boost имеет следующие недостатки....Вы не перечислили все недостатки. Некоторые javasripts или не работают как положено, или не работают вовсе. Пример, ajax cart, flag и др.
Я со своим компьютерным блогом участвую в конкурсе Блог Рунета 2011Друпалогия участвует в рейтинге Рунета среди порталов и сервисов
Сделал замеры drupal 6 на локальном апаче с включенным eaccelerator в разных режимах кэширования.
Результаты на чистом drupal 6, загрузка страницы node/1:
disabled — 95 мс
normal — 23 мс (встроенное кэширование)
boost — 10 мс
Результаты на реальном сайте www.tube.sfu-kras.ru запущенном локально, загрузка главной страницы:
disabled — 322 мс
normal — 23 мс
boost — 10 мс
Это с одним потоком. Тут запостил замеры с разным количеством потоков и параметры веб-сервера: edhel.krasu.ru/node/350
Результаты на чистом drupal 6, загрузка страницы node/1:
disabled — 95 мс
normal — 23 мс (встроенное кэширование)
boost — 10 мс
Результаты на реальном сайте www.tube.sfu-kras.ru запущенном локально, загрузка главной страницы:
disabled — 322 мс
normal — 23 мс
boost — 10 мс
Это с одним потоком. Тут запостил замеры с разным количеством потоков и параметры веб-сервера: edhel.krasu.ru/node/350
Еще хорошо бы все таблицы кеша и сессии перевести в memcache (модуль memcache правда вызвал баг с авторизацией, cacherouter в этом месте у меня не заработал).
На одном сайте при распечатке запросов devel-ом — нашел очень много дорогих запросов одинаковых для всех страниц (например поиск алиасов в блоках и вьюсах), я пропатчил модули, через cache_get, cache_set, в помощь select-у с хранением этого кеша в memcache. Это не рекомендация к действию, т.к. патчи-зло, но ситуацию выправить иногда позволит.
На одном сайте при распечатке запросов devel-ом — нашел очень много дорогих запросов одинаковых для всех страниц (например поиск алиасов в блоках и вьюсах), я пропатчил модули, через cache_get, cache_set, в помощь select-у с хранением этого кеша в memcache. Это не рекомендация к действию, т.к. патчи-зло, но ситуацию выправить иногда позволит.
Сacherouter как раз переносит таблицы кеша из базы и, вы правы, — сильно снижает нагрузку на rdbms.
Осмелюсь спросить о причинах неработоспособности cacherouter. Вы, простите, внимательно читали инструкцию по его установке? Там есть требование внести вызов и настройки бэкэнда в setings.php. Обычным методом «скопировал, активировал» он не запускается.
Осмелюсь спросить о причинах неработоспособности cacherouter. Вы, простите, внимательно читали инструкцию по его установке? Там есть требование внести вызов и настройки бэкэнда в setings.php. Обычным методом «скопировал, активировал» он не запускается.
Да, я немного слукавил, что не работает — пробовал довольно давно (бета наверно еще была), уже не помню с чем было связано, но перешел на memcache (а в settings записал, да).
С авторизацией (sessions и users в memcache) проблемы в memcache были такого рода — uid 1 (я) логинюсь без проблем, а остальные — «пользователь или пароль не верный» — на продакшн сайте не стал долго разбираться.
С авторизацией (sessions и users в memcache) проблемы в memcache были такого рода — uid 1 (я) логинюсь без проблем, а остальные — «пользователь или пароль не верный» — на продакшн сайте не стал долго разбираться.
memcache… а сколько у вас съедает памяти?
Агрессивное кеширование лучше использовать, если нет пометок, что у вас установлены модули, которые будут работать с ним некорректно. При этом модуль devel можно не учитывать — ему нечего делать постоянно запущенным на продакшне. У меня CAPTCHA работает нормально при агрессивном кеше, попробуйте и вы.
Большинство эффективных методов повышения производительности не применимы на shared хостингах. К ним я отношу установку memcached, php-fpm + nginx без apache, Varnish.
Из перечисленных методов самый эффективный это authcache + cacherouter. Советую добавить к ним ajax_blocks чтобы динамические блоки не мешали кешировать статику на большое время.
boost очень громоздкое средство. его имеет смысл использовать когда нет возможности поставить Varnish, когда не устраивают возможности обычных статических кешей и reverse proxies, ну и когда не жалко винчестера. Но Varnish намного гибче чем boost
Еще советую заменить ядро Drupal на Pressflow. Там много хороших оптимизаций.
Большинство эффективных методов повышения производительности не применимы на shared хостингах. К ним я отношу установку memcached, php-fpm + nginx без apache, Varnish.
Из перечисленных методов самый эффективный это authcache + cacherouter. Советую добавить к ним ajax_blocks чтобы динамические блоки не мешали кешировать статику на большое время.
boost очень громоздкое средство. его имеет смысл использовать когда нет возможности поставить Varnish, когда не устраивают возможности обычных статических кешей и reverse proxies, ну и когда не жалко винчестера. Но Varnish намного гибче чем boost
Еще советую заменить ядро Drupal на Pressflow. Там много хороших оптимизаций.
Существенно замедляет работу Drupal использование алиасов и переводов. Если без переводов, часто, не обойтись, то без использования алиасов, на мой взгляд, жить вполне можно. Для этого в файлике includes/path.inc сразу после строки
В этом случае при формировании каждой ссылки на странице на странице не будет осуществляться запрос к базе данных, что положительно скажется на производительности.
function drupal_lookup_path($action, $path = '', $path_language = '') {пишем return $path;В этом случае при формировании каждой ссылки на странице на странице не будет осуществляться запрос к базе данных, что положительно скажется на производительности.
А если хочется ЧПУ для всех страниц, не получится последовать этому совету?
В pressflow (форк друпала) есть замечательный модуль Path alias cache, который значительно ускоряет работу с синонимами (кеширует их).
Спасибо, хоть буду знать. Просто, уже давно не общался тесно с Drupal.
использую сейчас этот «замечательный модуль»… на очень большом проекте ведёт себя плохо… выдача ускоряется, но при попытке добавить новый алиас сервер уходит в глубокий даун из-за очистки кешей… с другой стороны на небольших проектах, о которых тут идёт речь многие средства хороши, даже буст… хотя опять же такие проекты отлично работают без сторонних средств кеширования да и без кеширования вообще даже на ник.ру… по крайней мере у меня
«существенно» — это что за единица измерения?) Только что devel-ом посмотрел сколько времени отнимают запросы из drupal_lookup_path на двух типовых страницах: в среднем 28 запросов, каждый запрос ~0,3 мс, в сумме ~3% времени от запросов и ~1.5% от всего времени генерации страницы. Не так уж и «существенно» имхо, анонимам с кэшем вообще по барабану на все эти запросы.
Конечно, кол-во запросов может быть и больше, если на странице больше вызовов url и l. Я без надобности их не использую в темах/модулях/блоках.
Конечно, кол-во запросов может быть и больше, если на странице больше вызовов url и l. Я без надобности их не использую в темах/модулях/блоках.
Это у вас хороший сервер, на шаред гостинге, да еще с диким оверселлом, борьба идет за каждый запрос.
тут нужно еще учитывать что тратится проц (на вызов этих запросов из ПХП) и память (если я конечно не ошибаюсь) ну и на диск нагрузка — БД ведь в виде файликов на диске лежит? (ну если без мемкеша)
Хотя мускул и показывает там 1 мс на запрос от алиаса, но их кеширование заметно ускоряет работу сайта, и реальная экономия (времени) по факту больше чем сумма всех миллисекунд от функции drupal_lookup_path в отчете девела.
С переводами — они так-же мелкие и вроде быстрые (по девелу), но отключение переводов дает по ощущениям прирост скорости админки ну в полтора раза точно. Если есть возможность я отключаю модуль locale — с английским у меня вроде проблем небыло.
Вот пара полезных трюков
xandeadx.ru/blog/drupal/110
xandeadx.ru/blog/drupal/16
Хотя мускул и показывает там 1 мс на запрос от алиаса, но их кеширование заметно ускоряет работу сайта, и реальная экономия (времени) по факту больше чем сумма всех миллисекунд от функции drupal_lookup_path в отчете девела.
С переводами — они так-же мелкие и вроде быстрые (по девелу), но отключение переводов дает по ощущениям прирост скорости админки ну в полтора раза точно. Если есть возможность я отключаю модуль locale — с английским у меня вроде проблем небыло.
Вот пара полезных трюков
xandeadx.ru/blog/drupal/110
xandeadx.ru/blog/drupal/16
Без тестов с цифрами не поверю, что кэширование алиасов может дать прирост более 5%. В общем потоке запросов — это небольшой процент простых запросов. Там где я тестировал, на главной странице — 156 запросов, а к алиасам — 19 и это самые лёгкие запросы в списке (еще к cache* быстрые запросы).
Посмотрел на нескольких сайтах размер таблицы url_alias: 7 кб, 8 кб, 133 кб, 13 кб, 17 кб, 6 кб.
Посмотрел на нескольких сайтах размер таблицы url_alias: 7 кб, 8 кб, 133 кб, 13 кб, 17 кб, 6 кб.
Реальный двухлетний проект. 123426 записей в таблице url_alias. Размер 32.9 Мб
Единственное где запрос к этой таблице превышает 1 секунду это формирование sitemap.xml модудем xmlsitemap (там запрос без where). В остальных случаях это самая безобидная таблица, как вы и утверждаете. Но с ростом посещаемости и объема данных я заметил, что дело уже не столько в тяжести запроса, сколько в самом количестве запросов. До какого-то момента устраивает и что системный cache находится в BD, а потом, когда объем запросов упирается в производительность rdbms (у каждого запроса есть блокировки, хоть к счастью не все они глобальные) и единственным способом увеличения производительности является уменьшение числа запросов любыми средствами. И тут самый дешевый это возможность кешировать отдельные таблицы вроде url_alias. Я и сам считаю, что это не очень большая оптимизация, но Pressflow это попытка выжать максимум. Там не только эта таблица кешируется, но и убираются LCASE везде, где можно. Я проверял, это существенно облегчает запросы. Там еще много всяких оптимизаций, в которых я пока не разобрался, а скоро у меня возникнет необходимость менять ядро Drupal на Рressflow.
Единственное где запрос к этой таблице превышает 1 секунду это формирование sitemap.xml модудем xmlsitemap (там запрос без where). В остальных случаях это самая безобидная таблица, как вы и утверждаете. Но с ростом посещаемости и объема данных я заметил, что дело уже не столько в тяжести запроса, сколько в самом количестве запросов. До какого-то момента устраивает и что системный cache находится в BD, а потом, когда объем запросов упирается в производительность rdbms (у каждого запроса есть блокировки, хоть к счастью не все они глобальные) и единственным способом увеличения производительности является уменьшение числа запросов любыми средствами. И тут самый дешевый это возможность кешировать отдельные таблицы вроде url_alias. Я и сам считаю, что это не очень большая оптимизация, но Pressflow это попытка выжать максимум. Там не только эта таблица кешируется, но и убираются LCASE везде, где можно. Я проверял, это существенно облегчает запросы. Там еще много всяких оптимизаций, в которых я пока не разобрался, а скоро у меня возникнет необходимость менять ядро Drupal на Рressflow.
Увы, в классическом виде не получится. В своём проекте ЧПУ делал на базе модулей. Т.е. создавал модуль, а в функции modulename_menu определял путь и функцию которая будет отвечать за вывод страницы.
> И вообще. Drupal удобен, но тяжеловесен. Приходится это признать.
В очередной раз убедился, что не зря в свое время решил не связываться с ним.
Есть ли в веб-природе такая ЦМСка, которая была бы
а) универсальной,
б) быстрой,
в) удобной для разработчиков,
г) бесплатной?
Пока остаюсь при мнении, что под разные задачи нужно использовать разные инструменты. И часто получается, что проще и приятнее написать самому, чем разбираться в чужом коде.
В очередной раз убедился, что не зря в свое время решил не связываться с ним.
Есть ли в веб-природе такая ЦМСка, которая была бы
а) универсальной,
б) быстрой,
в) удобной для разработчиков,
г) бесплатной?
Пока остаюсь при мнении, что под разные задачи нужно использовать разные инструменты. И часто получается, что проще и приятнее написать самому, чем разбираться в чужом коде.
На мой взгляд Drupal один из приятнейших примеров готовности бесплатнй CMF для широких решений. Он легковеснее многих других решений такого типа. Мне он показался и легче и одновременно мощнее чем Joomla, Magento и Typo3. Если вы хотите универсального но одновременно производительного решения, то советую присмотреться к Plone — у него хороший потенциал.
Думаю, тут вся загвоздка в универсальности! Уж больно широкое понятие.
Drupal-у я посвятил три года жизни. И моё мнение на счет целесообразности использования Drupal такое: Его целесообразно использовать как конструктор в тех случаях, когда необходимо собрать сайт человеку, который не хочет заморачиваться программированием.
Идеология исходного кода и функционирования Drupal, считаю, близка к идеальной. Но мне, к примеру, конфигурировать php-файл настроек было бы удобнее, чем использовать Web-интерфейс модуля CCK для добавления пользовательских полей в форму редактирования страницы. К тому же это бы избавляло от некоторого количества SQL-запросов, увеличивая производительность сайта в целом.
Поэтому около полутора лет назад я отказался от Drupal в пользу Django. Готовой системы управления сайтом на базе Django, удовлетворяющей меня не нашел. Пришлось писать свою, во многих моментах, причем, сохраняя идеологию работы Drupal. Возможно, она подойдет Вам по последним 3-м пунктам. Постараюсь в скором времени допилить ее и написать топик на хабре.
Drupal-у я посвятил три года жизни. И моё мнение на счет целесообразности использования Drupal такое: Его целесообразно использовать как конструктор в тех случаях, когда необходимо собрать сайт человеку, который не хочет заморачиваться программированием.
Идеология исходного кода и функционирования Drupal, считаю, близка к идеальной. Но мне, к примеру, конфигурировать php-файл настроек было бы удобнее, чем использовать Web-интерфейс модуля CCK для добавления пользовательских полей в форму редактирования страницы. К тому же это бы избавляло от некоторого количества SQL-запросов, увеличивая производительность сайта в целом.
Поэтому около полутора лет назад я отказался от Drupal в пользу Django. Готовой системы управления сайтом на базе Django, удовлетворяющей меня не нашел. Пришлось писать свою, во многих моментах, причем, сохраняя идеологию работы Drupal. Возможно, она подойдет Вам по последним 3-м пунктам. Постараюсь в скором времени допилить ее и написать топик на хабре.
Спасибо за советы! Пока буду использовать встроенное кеширование. На сайте как раз посетителей много а регистрируется мало.
Семерка, говорят, лучше работает с кешем. Я пока тестирую… Разницу чтобы заметить, нужно живой сайт делать на D7, но пока нет нескольких нужных модулей.
Почитал, подумал, и добавил кое-какие мысли по поводу кэширования. Сразу, на сайте над которым я работаю 4,5 миллиона уникальных просмотров в неделю, поэтому и меры слегка другие.
Sign up to leave a comment.
Кэширование на Drupal