Оценка нагрузки: RPS, трафик, хранилище, серверы
Расчёт RPS, пиковой нагрузки, трафика, объёма хранилища и числа серверов по пользователям и запросам - быстрая оценка для System Design.
Данные обрабатываются в браузере и никуда не отправляются
Ввод
Результат
Здесь появится результат
Введите данные слева - результат появится сразу
Как пользоваться
Введите исходные данные - число активных пользователей в сутки, запросы на пользователя, размеры запроса и ответа, долю записи, срок хранения - и таблица покажет нагрузку: средний и пиковый RPS, соотношение чтения и записи, трафик в пике, число одновременных запросов (по закону Литтла), объём новых данных и хранилища с репликацией, а также сколько серверов нужно с запасом. Для каждого показателя написано, как он считается.
Это грубая оценка порядка величин («back-of-envelope»), как на интервью по System Design и при первом планировании. Она не заменяет нагрузочное тестирование: реальные цифры зависят от кэшей, сети, базы данных и характера запросов.
Частые ошибки
Вот что искажает оценку нагрузки сильнее всего:
Средний RPS вводит в заблуждение
Нагрузка неравномерна: вечерний или акционный пик в 2-5 раз выше среднего, а при событиях вроде рассылки или распродажи - в десятки раз. Систему проектируют на пик, поэтому укажите реалистичный пиковый коэффициент.
Не учтён запас по загрузке
Сервер, загруженный на 90 процентов, отвечает всё медленнее, а при всплеске падает. Поэтому в расчёте стоит допустимая загрузка 50-70 процентов и резерв N+1 на отказ одного сервера.
Бит и байт, килобайт и килобит
Объёмы данных измеряют в байтах, а скорость сети - в битах в секунду: 1 МБ/с - это 8 Мбит/с. Путаница в 8 раз - самая частая ошибка в расчёте пропускной способности канала.
Забыли про репликацию и индексы
Данные хранятся в нескольких копиях (обычно 3), плюс индексы и служебные поля нередко занимают столько же, сколько сами данные. Фактические объёмы на диске в разы больше «чистого» размера записей.
Кэш и CDN уменьшают нагрузку, а не убирают её
Кэш снимает с базы и приложения значительную долю чтения, но промахи кэша и холодный старт создают пики. Не закладывайте 100 процентов попаданий в кэш при расчёте мощности хранилища.
Время обработки определяет параллелизм
Чем дольше обрабатывается запрос, тем больше их одновременно в работе при том же RPS. Закон Литтла: при 700 RPS и 100 мс получается около 70 одновременных запросов, а при 1 с - уже 700, а значит, нужно больше потоков, памяти и соединений.
Частые вопросы
Отправляются ли мои данные на сервер?
Нет - 100%. Сайт целиком статический, у него нет серверной части. Расчёты выполняются в вашем браузере, введённые числа никуда не отправляются.
Что такое DAU и откуда берут запросы на пользователя?
DAU (Daily Active Users) - число уникальных пользователей, активных за сутки. Запросы на пользователя берут из аналитики или оценивают: сколько экранов открывается, сколько вызовов API делает каждый экран. Для новой системы - из аналогичных продуктов.
Какой пиковый коэффициент брать?
Для обычных сервисов - от 2 до 5 к среднему за сутки, для событийных (продажи, ставки, билеты) - десять и больше. Если есть данные мониторинга, берите отношение максимума в минуту к среднему за сутки.
Что такое закон Литтла?
Среднее число одновременных запросов в системе равно интенсивности запросов, умноженной на среднее время обработки (L = λ·W). Он помогает прикинуть, сколько потоков, соединений и памяти нужно при заданной нагрузке и задержке.
Зачем резерв N+1?
Серверов должно хватать даже при отказе одного: тогда оставшиеся выдерживают пик. N - сколько нужно для пика, +1 - запас на отказ или на обновление без простоя. Для критичных систем закладывают N+2 или резерв на целую зону доступности.
Как оценить хранилище?
Умножьте число записей в сутки на размер одной записи, затем на срок хранения и коэффициент репликации. Прибавьте индексы, резервные копии и запас на рост. Инструмент считает данные с репликацией, остальное добавляйте по своей архитектуре.
Как перевести трафик в пропускную способность канала?
Входящий и исходящий трафик в пике показан в мегабитах в секунду: так измеряют каналы связи и сетевые карты. Сравнивайте с реальной пропускной способностью с запасом, потому что заполненный на 100 процентов канал даёт потери и задержки.
Насколько точна такая оценка?
Она даёт порядок величины: достаточно, чтобы понять, хватит ли одного сервера или нужен кластер, и сколько это примерно стоит. Точные числа получают нагрузочным тестированием реальной системы.
Похожие инструменты
Курс «Проектирование API и интеграций»
Глубокое погружение в REST, gRPC, SOAP, проектирование баз данных и брокеры сообщений (Kafka, RabbitMQ). Делегирование рутины нейросетям (ИИ). Перестанете бояться технических собеседований и начнете говорить с разработчиками на одном языке. Курс собран так, чтобы пробить зарплатный потолок и вырасти в грейде - ученики тому подтверждение.
Перейти к курсу на Stepik