А если на уровень ниже опуститься, базы данных и т.п. — что-нибудь такое же делаете, или это уже только в тестовом окружении отдельно тестируется?
Специально больших перекосов нагрузки на production-инстансы баз данных мы не создаем. Но в Яндексе существует практика регулярных учений по отключению локаций, в рамках которых нагрузка с одной локации снимается и автоматически перераспределяется на остальные. В эти моменты все компоненты сервисов и в т.ч. СУБД испытывают повышенную нагрузку и мы внимательно следим за метриками.
Если ничего не путаю, то слышал сколько-то лет назад, что dropbox так целиком окружение дублировал на основное и тестовое, и трафик на самом входе копировался туда и туда. Когда тестовое доказывало свою работоспособность, его ставили на место основного, а на основное ставили новую версию всего — и всё повторялось.
Тоже интересный подход, но полная копия всего окружения, если в нем живет большое количество сервисов – это, пожалуй, довольно дорого.
Еще, кстати говоря, Facebook пользуется для capacity-тестирования live-трафиком, они регулярно и автоматически повышают нагрузку той или иной локации, или кластера и снимают метрики.
Конечно, все запросы очень разные. Но в рамках данного проекта нам не нужна высокая точность и потому мы используем упрощенную модель, рассматривающую весь поток запросов как однородный, но качественно меняющийся во времени. И этого оказывается достаточно для оценки имеющихся ресурсов и планирования их потребления в будущем.
Отчасти именно из-за этого я отмечал тот факт, что методика подходит лишь для «высоконагруженных» сервисов, т.к. иначе результаты становятся слишком «шумными» на выходе.
Специально больших перекосов нагрузки на production-инстансы баз данных мы не создаем. Но в Яндексе существует практика регулярных учений по отключению локаций, в рамках которых нагрузка с одной локации снимается и автоматически перераспределяется на остальные. В эти моменты все компоненты сервисов и в т.ч. СУБД испытывают повышенную нагрузку и мы внимательно следим за метриками.
Тоже интересный подход, но полная копия всего окружения, если в нем живет большое количество сервисов – это, пожалуй, довольно дорого.
Еще, кстати говоря, Facebook пользуется для capacity-тестирования live-трафиком, они регулярно и автоматически повышают нагрузку той или иной локации, или кластера и снимают метрики.
Отчасти именно из-за этого я отмечал тот факт, что методика подходит лишь для «высоконагруженных» сервисов, т.к. иначе результаты становятся слишком «шумными» на выходе.