Как оценить ёмкость сервиса и не упасть под нагрузкой

[otchgol]

Как разработчику утилиты нагрузочного тестирования всегда было интересно услышать о реальных проектах!
Несколько странным для меня выглядит ориентация на количество запросов. Совершенно синтетическая характеристика. Понятно, что полностью пользователя симулировать сложно, но сделать примитивные действия по удержанию сессии и группировке нескольких запросов в рамках одной сессии мне кажется очевидным. Мне кажется очевидным, что загрузка первой страницы без авторизации и загрузка персонализированной страницы нагружает сервер по разному. Разные пользователи нарушают отработку кешированием и нагружают сервис иначе. Не это не являлось целью теста?

[GreyTomcat]

Конечно, все запросы очень разные. Но в рамках данного проекта нам не нужна высокая точность и потому мы используем упрощенную модель, рассматривающую весь поток запросов как однородный, но качественно меняющийся во времени. И этого оказывается достаточно для оценки имеющихся ресурсов и планирования их потребления в будущем.

Отчасти именно из-за этого я отмечал тот факт, что методика подходит лишь для «высоконагруженных» сервисов, т.к. иначе результаты становятся слишком «шумными» на выходе.

[otchgol]

Вероятно есть ниши, где достаточно простого бомбардирования запросами. Мне не понять. Всегда считал нагрузочное тестирование продолжением функционального. Потому и не понимал почему кто-либо может рассматривать скрипт как средство тестирования. Теперь понятно. Каждый останется при своем мнении. Мне такой тест кажется неполноценным, но тут каждому свое. Маркет вроде выдерживает запросы :)

[AKomarov]

отнеситесь к этому тесту, как к оценке верхней границы сервиса, которая из-за большого кол-ва пользователей, в последствии домножается на поправочный коэффициент, устанавливаемый опытным путем.

[otchgol]

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

[GreyTomcat]

А если на уровень ниже опуститься, базы данных и т.п. — что-нибудь такое же делаете, или это уже только в тестовом окружении отдельно тестируется?

Специально больших перекосов нагрузки на production-инстансы баз данных мы не создаем. Но в Яндексе существует практика регулярных учений по отключению локаций, в рамках которых нагрузка с одной локации снимается и автоматически перераспределяется на остальные. В эти моменты все компоненты сервисов и в т.ч. СУБД испытывают повышенную нагрузку и мы внимательно следим за метриками.

Если ничего не путаю, то слышал сколько-то лет назад, что dropbox так целиком окружение дублировал на основное и тестовое, и трафик на самом входе копировался туда и туда. Когда тестовое доказывало свою работоспособность, его ставили на место основного, а на основное ставили новую версию всего — и всё повторялось.

Тоже интересный подход, но полная копия всего окружения, если в нем живет большое количество сервисов – это, пожалуй, довольно дорого.

Еще, кстати говоря, Facebook пользуется для capacity-тестирования live-трафиком, они регулярно и автоматически повышают нагрузку той или иной локации, или кластера и снимают метрики.

[login40k]

Какими инструментами пользуетесь для подачи нагрузки? Если Танк, то не совсем технически понятно, как подложить в него access-лог. Можете детализировать немного? А так, крутой подход, к которому стоит стремиться, может не полностью, но идея с продакшен НТ — очень занимательная.

[GreyTomcat]

Если речь идет о тестировании живым трафиком – это типовые reverse proxy (например, haproxy) + небольшой самописный прокси-сервис, позволяющий нарезать трафик точно по RPS. Танк – он все-таки про оффлайн стенды.