Стоит ли пытаться воткнуть кэш везде, где только можно (memcached, проект на php)?
Есть работающий сайт, контентный проект с UGC. Много действий пользователей, много текстового контента. Сайт работает на одном сервере, основное хранилище информации mysql, для кэширования используется memchache.
Соотношение нагрузки таково:
MySQL: 101 запрос в секунду, 2 Гб трафика в час
Memcache: 40 запросов в секунду, 600 Мб трафика в час
Трафик: 40к уников, 350к просмотров в сутки (и ещё много действий через AJAX).
Я понимаю, что серебряной пули не бывает, но может кто-то из своего опыта скажет - стоит ли пытаться переложить нагрузку на кэш в тех случаях, когда экономия выйдет мизерной? Например, сейчас кэш практически не используется в блогах, комментариях, личных сообщениях - там очень много обновлений, выгода от введения кэша будет мизерной, а кодить много.
P.S. Сайт написан на голом php, общение с mysql через велосипед. В кэш отдавал пока те запросы, которые перебирают большие таблицы, либо запрашиваются сотни/тысячи раз между изменениями данных.
ReFeRy, тогда твой вопрос не корректный. Ты покажи с чем конкретно проблемы в пики. У тебя нагрузка на mysql сервер зашкаливает? или что? по тому что ты написал если у тебя не кривые запросы то всё должно быть ИЗИ
Андрей, вопрос в том, что будет эффективно для комплексного снижения нагрузки на железо. На данный момент все работает прекрасно, я ведь нигде и не писал, что есть проблемы :)
ReFeRy, так а что снижать если нагрузки нет? Воздух снижать? Тот же memcache может жрать до 10% CPU лишь при хранении одних сессий в нём. Mysql даже при 3к в секунду запросах не кривых и не тяжелых ничего вам не нагрузит.
Так что втыкать кеш mysql везде где только можно не очень идея. Например у меня воткнут на кое что что каждую секунду запрашивается. Вообщем всё индивидуально и смотреть надо по ситуации. Но в целом кеш надо втыкать тогда и только где он нужен и необходим.
1. Кешировать можно все, что позволяет кешировать бизнес-логика. Мизерный прирост в 10-ти местах может дать суммарно лучше прирост, т.к. эти мизерные запросы не будут лишний раз насиловать базу и база сможет быстрее обслуживать запросы.
2. Можно кешировать страницы и http запросы на уровне веб-сервера, до php запрос не должен дойти вообще - это может дать прирость общей производительности.
3. Если это что-то вроде блога, где посты меняются не так часто, а то и вообще не меняются, можно основные странички сгенерировать в уже готовый html и отдавать их как статику через web-сервер. Менять эти странички на серваке в случае какого-либо изменения.
Полностью статичных страниц очень мало, даже для незарегистрированных пользователей постоянно меняется порядок элементов, счетчики просмотров/комментариев/ подписчиков, блоки рекомендованного контента.
Сейчас вопрос именно с точки зрения баланса между выводом из БД и из кэша.
ReFeRy, ну счетчики и подобный контент можно загружать через ajax на страницу, если основная часть страницы, основной контент, не меняется то можго его выводить из статики, а что-то вроде счетчиков, ленты комментариев и т. п. подгружать динаически.
Хотя, конечно, это не просто и нужно отчетливо осознавать зачем это делать. Это существенно увеличит сложность системы в целом.
Я понимаю, что серебряной пули не бывает, но может кто-то из своего опыта скажет - стоит ли пытаться переложить нагрузку на кэш в тех случаях, когда экономия выйдет мизерной? Например, сейчас кэш практически не используется в блогах, комментариях, личных сообщениях - там очень много обновлений, выгода от введения кэша будет мизерной, а кодить много.
Не стоит.
Управление кешем сложная задача. А если кешировать всё подряд, то легко получить неконсистентное состояние и понять где беда будет не просто.
Ответить на ваш вопрос только обвесив сперва весь проект метриками.
Средний
