Дякую за те, що прочитали офіційну специфікацію 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% зросту від дна ринку (як в опозицію до поста, який писав вище). Успіхів!