Отслеживайте запрос, проходящий через clearnet / Cloudflare / Apache, чтобы точно определить проблемы с производительностью

Question

Я размещаю RESTful API, и моя проблема в том, что каждый первый входящий запрос через определенное время будет занимать около трех секунд, по сравнению с обычным ~ 100 мс.
Что мне наиболее интересно, так это то, что он всегда занимает точноОт 3100 до 3250 миллисекунд, не больше и не меньше.Так что мне это кажется довольно преднамеренным.

Я уже отладил API, и все работает практически мгновенно, за исключением одной вещи, и это три секунды, прежде чем мой API даже начнет получать запрос.
Я думаю, что что-то пошло не так, как в Apache, так и в разрешении DNS, но я не знаю, что именно вызывает (именно поэтому я задаю этот вопрос).

IЯ использую Apache ProxyPass следующим образом:

ProxyRequests off
Timeout 54
ProxyTimeout 5400
ProxyPass /jokeapi http://localhost:8079
ProxyPassReverse /jokeapi http://localhost:8079

Я использую DNS-серверы Cloudflare / APNIC 1.1.1.1 и 0.0.0.0
Кроме того, все мои запросы маршрутизируются через SSL-прокси Cloudflareпрежде чем даже достигнуть моей сети.

Я даже частично переписал API, чтобы он отвечал с помощью ReadStreams вместо загрузки файлов в ОЗУ и одновременного обслуживания, но это не решило проблему.

Мой вопрос заключается в том, как полностью отладить маршрут, по которому идет запрос, и точно определить, откуда происходит эта 3-секундная задержка.

Спасибо!

PS: сервер работает на NodeJS

Answer 1

Я думаю, что ключ не связан с сетевой активностью, но в примечании, что после периода простоя первый ответ на API через некоторое время требует чуть более 3 секунд. Я предполагаю, что последующие действия возвращаются к окну 100 мс.

Поскольку вы используете localhost, это не проблема маршрутизации. Если вы хотите, вы можете так же легко использовать loopback, 127.0.0.1, чтобы избежать попадания в разрешение имен, но такое попадание в зарезервированное имя хоста составило бы микросекунды.

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

Еще один элемент, который наносит ответный удар по сетевой стороне дома, - тайм-ауты DNS и записи в кэше привязки, как правило, довольно длинные, обычно значительная часть дня или даже дольше. Несмотря на это, вероятность того, что поиск DNS для элемента, который устарел из кэша привязки, не добавит три секунды к вашему начальному времени соединения.