Расчёт 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 (Daily Active Users) - число уникальных пользователей, активных за сутки. Запросы на пользователя берут из аналитики или оценивают: сколько экранов открывается, сколько вызовов API делает каждый экран. Для новой системы - из аналогичных продуктов.
Для обычных сервисов - от 2 до 5 к среднему за сутки, для событийных (продажи, ставки, билеты) - десять и больше. Если есть данные мониторинга, берите отношение максимума в минуту к среднему за сутки.
Среднее число одновременных запросов в системе равно интенсивности запросов, умноженной на среднее время обработки (L = λ·W). Он помогает прикинуть, сколько потоков, соединений и памяти нужно при заданной нагрузке и задержке.
Серверов должно хватать даже при отказе одного: тогда оставшиеся выдерживают пик. N - сколько нужно для пика, +1 - запас на отказ или на обновление без простоя. Для критичных систем закладывают N+2 или резерв на целую зону доступности.
Умножьте число записей в сутки на размер одной записи, затем на срок хранения и коэффициент репликации. Прибавьте индексы, резервные копии и запас на рост. Инструмент считает данные с репликацией, остальное добавляйте по своей архитектуре.
Входящий и исходящий трафик в пике показан в мегабитах в секунду: так измеряют каналы связи и сетевые карты. Сравнивайте с реальной пропускной способностью с запасом, потому что заполненный на 100 процентов канал даёт потери и задержки.
Она даёт порядок величины: достаточно, чтобы понять, хватит ли одного сервера или нужен кластер, и сколько это примерно стоит. Точные числа получают нагрузочным тестированием реальной системы.
REST, gRPC, SOAP, GraphQL и JSON-RPC, архитектурные подходы, SQL и NoSQL, брокеры сообщений и работа с ИИ. Программа курса помогает систематизировать знания об API и интеграциях; содержание и условия обучения смотрите на Stepik.