Сейчас cacherouter всё еще beta. Но работает стабильно. При этом самостоятельно переносит из базы все таблицы кеша на настроенный бэкенд (у меня memcached) чем сильно упрощает жизнь mysql и программисту ) В сочетании с authcache уменьшает нагрузку и от авторизованных.
Сacherouter как раз переносит таблицы кеша из базы и, вы правы, — сильно снижает нагрузку на rdbms.
Осмелюсь спросить о причинах неработоспособности cacherouter. Вы, простите, внимательно читали инструкцию по его установке? Там есть требование внести вызов и настройки бэкэнда в setings.php. Обычным методом «скопировал, активировал» он не запускается.
Агрессивное кеширование лучше использовать, если нет пометок, что у вас установлены модули, которые будут работать с ним некорректно. При этом модуль devel можно не учитывать — ему нечего делать постоянно запущенным на продакшне. У меня CAPTCHA работает нормально при агрессивном кеше, попробуйте и вы.
Большинство эффективных методов повышения производительности не применимы на shared хостингах. К ним я отношу установку memcached, php-fpm + nginx без apache, Varnish.
Из перечисленных методов самый эффективный это authcache + cacherouter. Советую добавить к ним ajax_blocks чтобы динамические блоки не мешали кешировать статику на большое время.
boost очень громоздкое средство. его имеет смысл использовать когда нет возможности поставить Varnish, когда не устраивают возможности обычных статических кешей и reverse proxies, ну и когда не жалко винчестера. Но Varnish намного гибче чем boost
Еще советую заменить ядро Drupal на Pressflow. Там много хороших оптимизаций.
1. Если по сценарию, приведенному здесь, то не одна. Если по принципу «меньше эффекта, за то меньше строчек», то я не могу разделить таких оснований для гордости. В любом случае APC и eAccelerator полезные вещи, но не повод отказываться от статического кеширования на популярном сайте.
2. Без этого условия сайту не нужна оптимизация средствами системного администрирования.
3. Такие сайты относятся к подавляющему меньшинству. При этом как раз в широко популярных социальных сетях статическое кеширование определенных частей контента выполняется наиболее часто, поскольку это самый дешевый метод повышения производительности. Конечно оно не применяется для частей, требующих мгновенной реакции, но, повторяю — статическое кеширование применимо на подавляющем большинстве сайтов. Если ваш сайт не имеет возможности пользоваться статическим кешированием, отдавая 100% пользовательской нагрузки на движок, то для такого проекта появляется слишком много ограничений. php с его cgi-архитектурой обнуления состояний между запросами, mysql c его нелинейной регрессией производительности при увеличении объемов данных в реляционных соединениях и блокировками делают производительность измеряемой десятками запросов в секунду. И это на фоне производительности в тысячи запросов в секунду для fastcgi_cache_*
Всё, что я хочу сказать, что те 5-10 строчек конфига nginx, которые отвечают за кеширование являются важной частью для большого числа сайтов, к которым относится эта статья и вы зря от них отмахнулись.
~$ echo "this is 1" > file1
~$ ln ./file1 file2
~$ cat file2
this is 1
~$ echo "this is 3" > file3
~$ mv file3 file1
~$ cat file2
this is 1
~$ cat file1
this is 3
Вы правы. Спасибо. Век живи, век учись, дураком помрешь.
Давайте я уточню свое мнение и больше не буду претендовать.
1. Заморачиваться с fastcgi_cache_* в рамках этой статьи логично и не выходит за них, чего не скажешь про APC. Все заморачивание с fastcgi_cache_* состоит из дополнительных 5-10 строк к уже написанному конфигу nginx. говорить, что установка APC проще в данном контексте просто нелепо.
2. Разница в ускорении работы сайта при fastcgi_cache_* и при простом opcode-cache настолько существенная, что про APC вообще можно было не вспоминать. это как сравнить для автомобиля прирост скорости от установки в 10 раз более мощного двигателя и изменение аэродинамики кузова на 0.1 Это решения разных порядков эффективности.
3. Для большинства сайтов вопрос инвалидизации кеша стоит не сильнее, чем установка допустимого времени задержки обновления. 10 минут можно считать идеальным для подавляющего большинства часто обновляемых сайтов. А для редко обновляемых можно кешировать и на час. Только новостные сайты требуют более оперативного обновления, но там в механизме инвалидизации кеша нет надобности из-за очень короткого кеширования основных страниц и фидов.
С другой стороны, если почти каждый браузер запрашивает favicon.ico и каждый поисковый бот — robots.txt, то идеологически правильно их создать и предоставить.
Конечно. А у вас есть сомнения, что правила выборочной инвалидизации данных, подчиненных архитектуре конкретной системы относятся к компетенции разработчика, а не админа?
Если честно, то после массовых жалоб реальных пользователей эксперименты на сферической теории не вдохновляют. Но вы, конечно, развлекайтесь. Сделайте экспериментальную выборку побольше — глюк с непониманием заголовка сжатия, если я правильно помню, проявлялся где-то в 10-15% по отношению к случайным страницам. У меня в тот момент было всего 4000-5000 хитов из которых на IE6 приходилось где-то 60% Это давало 20-30 писем и 10-15 звонков с жалобами на поломку страницы.
Надо запускать php-fpm с разными конфиг файлами, где указаны разные php.ini с разными пользователями и разными chroot. Это решение не для массового применения и на мой взгляд — только лишняя трата ресурсов.
И для библиотеки должны пойти, если etc, lib и www находятся на одном разделе. А это крайне нежелательно с точи зрения стабильности системы, почему во многих рецептах и советуют копировать, а не линковать.
Осмелюсь спросить о причинах неработоспособности cacherouter. Вы, простите, внимательно читали инструкцию по его установке? Там есть требование внести вызов и настройки бэкэнда в setings.php. Обычным методом «скопировал, активировал» он не запускается.
Большинство эффективных методов повышения производительности не применимы на shared хостингах. К ним я отношу установку memcached, php-fpm + nginx без apache, Varnish.
Из перечисленных методов самый эффективный это authcache + cacherouter. Советую добавить к ним ajax_blocks чтобы динамические блоки не мешали кешировать статику на большое время.
boost очень громоздкое средство. его имеет смысл использовать когда нет возможности поставить Varnish, когда не устраивают возможности обычных статических кешей и reverse proxies, ну и когда не жалко винчестера. Но Varnish намного гибче чем boost
Еще советую заменить ядро Drupal на Pressflow. Там много хороших оптимизаций.
2. Без этого условия сайту не нужна оптимизация средствами системного администрирования.
3. Такие сайты относятся к подавляющему меньшинству. При этом как раз в широко популярных социальных сетях статическое кеширование определенных частей контента выполняется наиболее часто, поскольку это самый дешевый метод повышения производительности. Конечно оно не применяется для частей, требующих мгновенной реакции, но, повторяю — статическое кеширование применимо на подавляющем большинстве сайтов. Если ваш сайт не имеет возможности пользоваться статическим кешированием, отдавая 100% пользовательской нагрузки на движок, то для такого проекта появляется слишком много ограничений. php с его cgi-архитектурой обнуления состояний между запросами, mysql c его нелинейной регрессией производительности при увеличении объемов данных в реляционных соединениях и блокировками делают производительность измеряемой десятками запросов в секунду. И это на фоне производительности в тысячи запросов в секунду для fastcgi_cache_*
Всё, что я хочу сказать, что те 5-10 строчек конфига nginx, которые отвечают за кеширование являются важной частью для большого числа сайтов, к которым относится эта статья и вы зря от них отмахнулись.
Вы правы. Спасибо. Век живи, век учись, дураком помрешь.
1. Заморачиваться с fastcgi_cache_* в рамках этой статьи логично и не выходит за них, чего не скажешь про APC. Все заморачивание с fastcgi_cache_* состоит из дополнительных 5-10 строк к уже написанному конфигу nginx. говорить, что установка APC проще в данном контексте просто нелепо.
2. Разница в ускорении работы сайта при fastcgi_cache_* и при простом opcode-cache настолько существенная, что про APC вообще можно было не вспоминать. это как сравнить для автомобиля прирост скорости от установки в 10 раз более мощного двигателя и изменение аэродинамики кузова на 0.1 Это решения разных порядков эффективности.
3. Для большинства сайтов вопрос инвалидизации кеша стоит не сильнее, чем установка допустимого времени задержки обновления. 10 минут можно считать идеальным для подавляющего большинства часто обновляемых сайтов. А для редко обновляемых можно кешировать и на час. Только новостные сайты требуют более оперативного обновления, но там в механизме инвалидизации кеша нет надобности из-за очень короткого кеширования основных страниц и фидов.