Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
А что скажите насчет Boost? Если сайт рассчитан в первую очередь на анонимов (который просто читают, но не регистрируются, ничего не комментят и т.д.), то с ним сайты вообще летают, разве нет?
Если сайт предназначен только для анонимов, то и встроенного кеширование страниц для анонимных пользователей будет вполне достаточно.
Если хотите быстрее буста, то вам поможет Varnish
У меня был печальный опыт с Boost. После его установки сайт на 1000+ страниц за два дня полностью выпал из кэша Яндекса. С гуглом всё нормально, специально подождал до апа и у гугла ничего не поменялось. После отключения модуля Яндекс заново сайт индексировал пол года. Из того, что показало расследование, апач сообщал один размер страницы, а отдавал другой. Кто виноват — непонятно. Гуглу, как оказалось, на это наплевать, а вот Яндекс пометил все страницы как битые и удалил из кэша.
И в принципе, даже если откинуть эту проблему — тут идёт кэширование диском, да ещё и создаётся туева хуча файлов. Это всё очень сильно нагружает ФС. А если юзать memcashed или Redis — кэш живёт в оперативке, при чём возможно даже на отдельной машине. Для тяжеловесных проектов очень даже. Видел даже вариант использования MongoDB в качестве кэша — скорость в 2-3 раза ниже чем у memcashed (при условии хранения данных в оперативке), но потенциально больше возможностей.
И в принципе, даже если откинуть эту проблему — тут идёт кэширование диском, да ещё и создаётся туева хуча файлов. Это всё очень сильно нагружает ФС. А если юзать memcashed или Redis — кэш живёт в оперативке, при чём возможно даже на отдельной машине. Для тяжеловесных проектов очень даже. Видел даже вариант использования MongoDB в качестве кэша — скорость в 2-3 раза ниже чем у memcashed (при условии хранения данных в оперативке), но потенциально больше возможностей.
Странно, первый раз слышу о такой проблеме с Boost'ом. Сам использую его на 6 сайтах объемом 300-800 страниц, и с посещаемость несколько тысяч человек в день (99% — анонимы). Нравится, что страницы для них грузятся практически мгновенно. Но как раз опасаюсь побочных эффектов из-за файлового кеширования.
Поэтому интересует, что лучше использовать для сайтов объемом до 2000 страниц и с посещаемостью до 20 000 человек в день (99% — анонимы). Мне кажется, что в данном случае Boost — оптимален с точки зрения производительности. Или нет?
Поэтому интересует, что лучше использовать для сайтов объемом до 2000 страниц и с посещаемостью до 20 000 человек в день (99% — анонимы). Мне кажется, что в данном случае Boost — оптимален с точки зрения производительности. Или нет?
Какие плюсы\минусы у Entity cache? Ведь они есть? Иначе бы был включен в коробку наверное?
Статья с серьёзной ошибкой.
при включении мемкэша/редиса вдруг с самого первого раза начинает всё за 2 секунды работать вместо 30ти, что не может быть верным. Без кэша-то user_load() всё равно все данные из бд тянутся. И не редис, не мемкэш это ускорить не могут. Максимум где здесь можно получить ускорение — за счёт скорости записи в память вместо бд. Но это никак не разница в 28 секунд.
это я вот к этому «И — сходу успех, первый запуск выполняется всего за 2,8 секунды вместо 30».
это нереальное значение. А кто-то верит.
это явно не запуск с нуля, а чтение каких-либо данных из кэша.
©Spleshka
при включении мемкэша/редиса вдруг с самого первого раза начинает всё за 2 секунды работать вместо 30ти, что не может быть верным. Без кэша-то user_load() всё равно все данные из бд тянутся. И не редис, не мемкэш это ускорить не могут. Максимум где здесь можно получить ускорение — за счёт скорости записи в память вместо бд. Но это никак не разница в 28 секунд.
это я вот к этому «И — сходу успех, первый запуск выполняется всего за 2,8 секунды вместо 30».
это нереальное значение. А кто-то верит.
это явно не запуск с нуля, а чтение каких-либо данных из кэша.
©Spleshka
Тут явно I/O просаживается, а не drupal. Помониторьте работу БД и I/O, ясное дело что Redis даст прирост. Хостера поменяйте и будет счастье, так как с 2014 года и даже раньше все вменяемые хостеры перешли на SSD. user_load грузит не просто пользователя в виде одной записи из БД, а все его поля которые хранятся в отдельных таблицах для поддержки версионности. Т.е. для загрузки 1000 пользователей нужно сделать раз в 5 больше запросов (они всё же быстрее выполняются чем если бы всё сериализовано хранилось в одной таблице) к б.д. и база мрёт на I/O. Поэтому Drupal тут ни при чём, статья любопытная, но не о чём.
Для кэширования статей в Drupal рекомендую статью: Отдаём кэш анонимов без поднятия бэкэнда. Drupal 7 + nginx + memcached — drupalace.ru/lesson/otdayom-kesh-anonimov-bez-podnyatiya-bekenda-drupal-7-nginx-memcached от нашего общего товарища с ником: Spleshka.
Для кэширования статей в Drupal рекомендую статью: Отдаём кэш анонимов без поднятия бэкэнда. Drupal 7 + nginx + memcached — drupalace.ru/lesson/otdayom-kesh-anonimov-bez-podnyatiya-bekenda-drupal-7-nginx-memcached от нашего общего товарища с ником: Spleshka.
Прирост производительности при первом запросе действительно большой и получается он за счёт отсутствия INSERT запросов в таблицы кеша друпала (кеш полей и кеш сущности).
На самом деле кеширование — очень даже интересный аспект и не только в Друпале. При использовании кеширования самих сущностей (Entity), нужно быть очень акуратным, именно в том плане, что после подключения кеширования необходимо записывать/читать данные только используя Ваш код с кеширующим слоем, и ни в коем случае нельзя уже тогда менять прямо в БД, или через другие скрипты.
Хотел бы еще добавить, относительно выбора «Cache Storage»: в частности, большинство стают перед выбором Redis vs Memcache(d).
Здесь необходимо понимать, что такое Memcache(d) и что такое Redis
Memcached — это key & value хранилище. Имеет ряд недостатков, главным из которых есть выброс старых ключей, если есть нехватка памяти. То есть, к примеру у Вас там только 16 Мб. Вы загрузили туда кешей на все 16 Мб. После этого, если Вы будут вставлять в него новые данные, старые будут удалены. Во время перезагрузки Вы тоже потеряете данные.
Redis — это не только key & value хранилище, но и полноценное хранилище для других типов данные, таких как HASH, LIST. При этом, есть очень хорошая поддержка Lua-скриптов и другого нативного функционала, что иногда очень упрощает жизнь. Большой плюс — это «сливание данные» на винт (если указано в конфиге), в результате, данные при перезагрузке потеряны не будут. Также в нем очень хорошо распределяется память (я бы сказал лучше чем у memcached). Выбор на этот «монстр» нельзя делать только для использования key & value!
Моя практика показывает, что кеширования сущностей, дает слабоватый прирост производительности ПО СРАВНЕНИЮ с HTTP кешированием. Было бы очень интересно посмотреть на возможности кеширования Varnish, Nginx + Memcached (или другие связки) в самом Друпале.
Хотел бы еще добавить, относительно выбора «Cache Storage»: в частности, большинство стают перед выбором Redis vs Memcache(d).
Здесь необходимо понимать, что такое Memcache(d) и что такое Redis
Memcached — это key & value хранилище. Имеет ряд недостатков, главным из которых есть выброс старых ключей, если есть нехватка памяти. То есть, к примеру у Вас там только 16 Мб. Вы загрузили туда кешей на все 16 Мб. После этого, если Вы будут вставлять в него новые данные, старые будут удалены. Во время перезагрузки Вы тоже потеряете данные.
Redis — это не только key & value хранилище, но и полноценное хранилище для других типов данные, таких как HASH, LIST. При этом, есть очень хорошая поддержка Lua-скриптов и другого нативного функционала, что иногда очень упрощает жизнь. Большой плюс — это «сливание данные» на винт (если указано в конфиге), в результате, данные при перезагрузке потеряны не будут. Также в нем очень хорошо распределяется память (я бы сказал лучше чем у memcached). Выбор на этот «монстр» нельзя делать только для использования key & value!
Моя практика показывает, что кеширования сущностей, дает слабоватый прирост производительности ПО СРАВНЕНИЮ с HTTP кешированием. Было бы очень интересно посмотреть на возможности кеширования Varnish, Nginx + Memcached (или другие связки) в самом Друпале.
Drupal 7 + nginx + memcached получается быстрее чем с Varnish, так же памяти меньше расходуется. Точные замеры не делал. Как настроить, написал топиком выше.
Я видел что написали, спасибо.
Я не думаю, что nginx + memcached будет быстрее чем Varnish. Здесь скорее уже надо полноценно замерять.
В большинстве случаев думают что Варниш будет хуже работать, так как пишет кеши на диск. Но не следует забывать, что раздел можно подцепить на оперативную память, и тогда он точно также будет писать как и Memcached.
Также, в Варнише есть очень прикольная штука ESI — что может в разы увеличить производительность некоторых разделов сайта/портала.
Я не думаю, что nginx + memcached будет быстрее чем Varnish. Здесь скорее уже надо полноценно замерять.
В большинстве случаев думают что Варниш будет хуже работать, так как пишет кеши на диск. Но не следует забывать, что раздел можно подцепить на оперативную память, и тогда он точно также будет писать как и Memcached.
Также, в Варнише есть очень прикольная штука ESI — что может в разы увеличить производительность некоторых разделов сайта/портала.
Отвечу какие вижу изъяны в Varnish, хотя ESI в нём замечательная штука, но предпочитаю с помощью JS грузить части страниц кэшируя их в Nginx + Memcached (получается почти то же самое, но руками делать нужно больше). Итак по изъянам:
1. Varnish будет медленнее из за I/O чем Memcached. Виртуальный диск это уже не для среднего уровня.
2. Memcached можно развернуть в кластер с помощью mcrouter (https://code.facebook.com/posts/296442737213493/introducing-mcrouter-a-memcached-protocol-router-for-scaling-memcached-deployments/).
3. Varnish менее производительный чем Squid (https://ru.wikipedia.org/wiki/Squid).
4. Когда серверов много, то на основе куки можно определить с какого сервера только, что запрашивал страницу пользователь и направить на получение страниц именно туда его, делает это nginx. Т.е. под разные языки сайта стоят разные сервера и на входи балансим пользователя на нужный сервак а там из Memcached отдаём статику. Для очень большого проекта это очень удобно.
В остальном для средних по размеру сайтов он Великолепен. Ставится минимум настроек и сразу получается ускорение которого достаточна для большинства сайтов. Так же например можно для Drupal поставить модуль SDN в котором настроить роутинг картинок на поддомен и на поддомене раздавать картинки через Varnish кэшируя их в памяти. В таком случае так же получаете хорошую скорость загрузки всей страницы.
1. Varnish будет медленнее из за I/O чем Memcached. Виртуальный диск это уже не для среднего уровня.
2. Memcached можно развернуть в кластер с помощью mcrouter (https://code.facebook.com/posts/296442737213493/introducing-mcrouter-a-memcached-protocol-router-for-scaling-memcached-deployments/).
3. Varnish менее производительный чем Squid (https://ru.wikipedia.org/wiki/Squid).
4. Когда серверов много, то на основе куки можно определить с какого сервера только, что запрашивал страницу пользователь и направить на получение страниц именно туда его, делает это nginx. Т.е. под разные языки сайта стоят разные сервера и на входи балансим пользователя на нужный сервак а там из Memcached отдаём статику. Для очень большого проекта это очень удобно.
В остальном для средних по размеру сайтов он Великолепен. Ставится минимум настроек и сразу получается ускорение которого достаточна для большинства сайтов. Так же например можно для Drupal поставить модуль SDN в котором настроить роутинг картинок на поддомен и на поддомене раздавать картинки через Varnish кэшируя их в памяти. В таком случае так же получаете хорошую скорость загрузки всей страницы.
В частности друпальный модуль полноценно работает с редисом через HASH. И по сравнению с мемкешем правильно обрабатывает очистку кеша по вайлдкарду.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Basic performance. Заставим Drupal летать. Часть I