(TTFB) Для некоторых конкретных запросов требуется больше времени, чем для выполнения фактического запроса.

Question

заголовок может показаться немного расплывчатым, вот подробности моей проблемы. У меня есть веб-приложение, которое состоит из 3-х уровней, углового внешнего интерфейса, промежуточного программного обеспечения шлюза API .NET Core и проекта .NET в качестве внутреннего уровня. Все эти 3 проекта отделены друг от друга и работают нормально. Моя проблема в том, что на большинстве конечных точек, которые у меня есть в моем проекте, запросы выполняются, как ожидается, в мс-уровнях и возвращают данные, но некоторые из них, как представляется, ожидают неопровержимого времени, и это происходит случайным образом. Выходные данные хронирования ответа Chrome для упомянутого запроса GET показаны ниже.

Детали синхронизации Chrome

Как вы можете видеть выше, большая часть времени, проведенного здесь, предназначена для ожидания. Кроме того, я отслеживал подобные запросы в стекизации, и кажется, что запрос выполняется в мс-уровнях в проекте back-end . Вывод Stackify показан ниже.

Стабилизация вывода трассировки

Как показано выше, мой внутренний ответ длился не более 835 мс и возвращал соответствующий ответ. Наконец, из журналов, которые мой шлюз создает в Кибане, у меня был следующий журнал синхронизации, который также показывает, что запрос занял ~ 8 секунд.

Api Gateway Log

Подводя итог, можно ожидать ответа в моем проекте API-шлюза (.NET Core), и я понятия не имею, почему это происходит случайным образом на некоторых конечных точках. Наконец, я просто отправляю запрос соответствующим конечным точкам в моем проекте API-шлюза, и никаких операций не производится. Чтобы понять и исправить эту проблему, любая помощь и предложение приветствуются заранее.

Answer 1

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

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

Единственное надежное решение, которое я смог найти, не очень научное: после развертывания просто отправьте пару запросов на прогрев конечным точкам API.

Как описано выше, для меня решение состоит в том, чтобы отправить фактический запрос http в мой проект API. Надеюсь, это поможет тем, у кого такая же проблема, как у меня.

Answer 2

Если приложение переходит в автономный режим, потребуется еще несколько секунд, чтобы снова подключиться к сети, в большинстве случаев именно поэтому TTFB (время до первого буфера) занимает много времени для ответа.

еще один возможный случай; если запрос используется для получения изображений, причиной может быть размер изображений.

И последнее, но не менее важное: вы можете попытаться уменьшить нагрузку на серверную часть сервера.

у этого поста та же проблема: Как я могу сократить время ожидания (ttfb)