Hw 03

[KonstantinFrantz]

Кейс №3

• ratePerSecond = 2
• testCount = 500
• processingTimeMills = 60000

Данные аккаунта:

• parallelRequests=5
• rateLimitPerSec=3
• averageProcessingTime=PT4.9S

На наш сервис приходит 500 запросов по 2 в секунду, тоесть последний запрос прийдет через 500 / 2 = 250 с. (Это можно заметить на графике в виде пересечения оранжевой линии оси абсцисс через ≈ 4:10 минуты)
Актуальный rate принимаемых сервисом оплаты запросов можно вычеслить как 5 / 4.9 ≈ 1. Тоесть при заявленной пропускной способности в 3 запроса в секунду, на самом деле платежная система в секунду может обрабатывет лишь один.

Так как входной rps 2, а принимаемый системой оплаты 1, запросы начинают копиться в "очереди" с приблизительной скоростью 1 rps. Всвязи с чем, уже через минуту от начала теста ожидание в очереди становится ≈ 50 секунд (входной rate растет постепенно), что равно времени ожидания клиента ответа. Вот почему через (45\55) + 60 ≈ 110 секунд нам начинают приходить первые client_timeout. (Заметно по поведению красного графика, начинающего стремительно расти вверх спустя ≈ 2 минуты от начала запуска теста)

К моменту отправки последнего запроса от клиента, время ожидания в "очереди" составляет +-90 секунд, после которых клиенту приходит последний ответ от системы. (Время пересечения синей линии оси абсцисс)

Время которое сервис затратит на обработку всех запросов высчитывается как 500 * 4.9 / 5 = 490 с. В то время как 250 + 60 = 310 с. - время в которое последний клиент уйдет с нашего сайта в связи превышением времени ожидания.
Получается при заданных входных параметрах все запросы клиентов обработать в срок невозможно.