Сервис получает 800 requests per second на эндпойнт. Какая грубая прикидка оценка requests per day ближе всего?
AОколо 70 тыс
requests per dayBОколо 70 млн
requests per dayCОколо 7 млн
requests per dayDОколо 700 млн
requests per dayПравильный ответ. Перевод из
per second в per day — это умножение на число секунд в дне и проверка units.Разбор
В сутках 86 400 секунд, поэтому 800 requests per second дают около 69 млн requests per day. Такая прикидка помогает оценить нагрузку и лимиты до подробных расчётов. Ошибки чаще всего связаны с потерянным нулём или смешением units. Для upper bound можно учитывать пик нагрузки, а не среднюю.
Проверь себя · 1/3разбор после ответа
У вас 2.5 млн
events в день и нужно прикинуть объём events в месяц для планирования. Какой грубая прикидка перевод units самый разумный?Ещё вопросы по теме «Sanity-check и оценка»
- В дашборде метрика `conversion` определена как доля пользователей, совершивших хотя бы одну покупку за день. В отчёте вы видите 130%. Какой грубая прикидка `sanity-check` по `constraints` наиболее уместен?
- У вас 2.5 млн `events` в день и нужно прикинуть объём `events` в месяц для планирования. Какой грубая прикидка перевод `units` самый разумный?
- Каждое событие занимает примерно 1 `KB` в логах, а в день приходит 50 млн `events`. Какой `order of magnitude` для суточного объёма данных ближе всего, если сделать грубая прикидка оценку по `units`?
- У продукта 200 тыс `DAU`. Доля платящих пользователей около 2%, а средний платёж в день на платящего — 500 ₽. Какая грубая прикидка оценка дневной выручки по `units` наиболее адекватна по `order of magnitude`?
- ETL job обработал 120 млн строк за 2 часа. Какой грубая прикидка `throughput` в `rows per second` ближе всего?
- Все вопросы по «Sanity-check и оценка» →