ПостДякую за те, що прочитали офіційну специфікацію GCP і проголосували. Я зупинив опитування.

Дякую за те, що прочитали офіційну специфікацію GCP і проголосували. Я зупинив опитування. По результатам також видно конфуз: - 49% Server Side Request Latency - 12% TTFB - 12% RTT - 28% Total Response Time Поясню причину unexpected behaviour: - по опису метрики, яку я закинув з офіційної доки - очевидно це Server Side Request Latency - тут пишуть що це Total Response Time, а в коментах - що RTT - тут пишуть що це Total Response Time - в коменті до опитування пишуть, що взагалі НЕМАЄ правильної відповіді - ще є купа тредів і форумів де люди конфьюзяться В моєму випадку я помітив цю штуку на slow clients на пет-проджекті, і грішив на бекенд. Далі зробив profiling + tracing, також k6 перформанс тести і зрозумів що в мене немає жодних питань до бекенду. Але є дуже багато питань до метрики 😆 З моєї сторони, значення яке туди потрапляє виглядає як Total Response Time, і пруфається через curl --limit-rate ➡️ Тепер я попрошу GCP сертифікованих інженерів, або тих хто точно знає зайти в коменти сюди, і дати відповідь що є дійсно таке HttpRequest.latency в логах GCP до балансера Сподіваюсь розберемось разом, на тижні ще закину чудову статтю з Pragmatic Engineer про стан ІТ в 2025, де є +40% зросту від дна ринку (як в опозицію до поста, який писав вище). Успіхів!