Второй тизер

У меня появилось время написать продолжение истории про то, как "Куда все идут" падал под трафиком с тизера (часть 1, часть 2). Сразу скажу, что рушится все обычно гораздо громче, чем не рушится, поэтому этот пост на захватывающую историю не претендует совсем.

Показатели

Итак, второй тизер для нас висел еще аж в позапрошлый четверг, 6 марта. Был он, правда, не постоянный, а появлялся с вероятностью примерно в 20%. Это, понятное дело, была перестраховка, и вылилась она в то, что нагрузка была очень маленькой: 27 запросов/сек в пике.

Тут, кстати, для меня загадака, откуда взялись наши 300 запросов/сек в прошлый раз. Если 27 умножить на 5 (что уже преувеличение), то получится только 135. Думаю, что может быть зависимость между вероятностью показа и трафиком нелинейная, а может быть мы в тот раз что-то лишнее не от-grepили из статистики :-).

Однако, даже на таком небольшом потоке можно сказать, что своего мы достигли: нагрузка на систему весь день валялась в полном нуле, LA не забирался выше десятых долей. И я думаю, что эту нагрузку раз в пять увеличивать можно легко. Можно и больше даже. Правда, практически проверить мы это сможем не очень скоро. Помимо чисто технических показателей тизер дал нам понять, что звать в большом количестве народ к нам пока не очень интересно. Поэтому мы сначала прикрутим несколько фичек повкуснее, и тогда уж — снова.

Решения

Все решения, которые я перечислял в прошлом посте были сделаны и сыграли свою роль.

Если я правильно читаю хрустальный шар статистику тестового стенда, то больше всего воздуху сервису дает мягкое протухание кеша. Правда, мы не стали использовать MintCache напрямую, а просто позаимствовали идею в своем коде, так удобней оказалось.

Обещанный мной бэкенд, который сдружил Django с репликацией MySQL я тоже написал, и больше того, мы собираемся его опубликовать в ближайшее время (вот только README на английский переведу :-) ). Но в нашем конкретном случае он, правда, не дал много, потому что у нас реально много тяжелых запросов на сервисе, поэтому кешировать результат существенно эффективней, чем просто размазывать тяжелый SQL по бэкендам.

Интересно, сколько на этот раз найдется людей, которые после этого предложения напишут в RSDN и на Хабре, что-нибудь типа "Django плохо работает с репликацией" :-)

Но в любом случае реплики играют свою роль хотя бы просто для надежности. Даже если у нас отключится датацентр, в котором стоит мастер-база, то мы, по идее, должны теперь нормально работать в read-only режиме.