ну ок.
тогда смотрите
обычно я персентили не считаю
обычно я делю latency на несколько бакетов и задаю этим бакетам границы исходя из требования к сервису
а дальше рисую stacked диаграмму по кол-ву запросов в каждом бакете за единицу времени
и зеленым\синим отображаю "безопасные" бакеты, а "желтым" и "красным" - "опасные"

обычно значения 0-0.2sec, 0.2-0.5sec, 0.5-2sec, 2+sec
но для ваших сервисов требования могут быть другие

Ну похоже вы не верно понимаете event-loop - когда сервис отправил тысячи запросов в апи и занялся вычислительной работой -  тысячи запросов аисят и время тикает пока не разгрузится основной поток и лишь после этого он начнет разгребать завалы с пришедшими ответами апи но тут навалят новыз запросов и основной поток опять загружен но не все пришедшие от апи ответы будут обработаны - вот они то и попадают в 90е перцентили

но это требует по другому агрегировать latency где нибудь в statsd через hystogram

я верно понимаю евентлуп
еще раз, евент луп сам по себе не узкое место
если вы зафигачили евентлуп а сами в нем занимаетесь бесконечно неээфективным парсингом здоровых JSON, то вы сами себе злобные буратины

Да нет я этим не занимаюсь - я не извращенец😊
И даже из бд json частично возвращаю строками чтоб меньше парсил сервис - просто большой объем запросов может прийти лавинообразно и как бы вы не оптимизировали код - event-loop будет перегружен

в общем CPU bound + async io, угу, такое себе
снижайте CPU bound
если у вас CPU Utilization близкое к 100%
анализ flamegraph  вам в помощь
и SIMDJSON вам в помощь

ну это я все забываю, что nodejs же однопоточный
ну вроде  же там можно пул процессов запустить
разгребут если ядер хватит

ладно в общем да, latency не всегда берется из IO ;)
ну про бакеты и гистограммы я надеюсь вы поняли

Да есть у меня и гистрограммы с бакетами 😊
Но они же по принципу квантилей работают - насыпают и во все нижестоящие бакеты - т.е. тот же потолок видим а не течение основной массы

вот пример и проц не нагружен и разница в квантилял большая q50 и q90
и что из этого можно понять? ровным счетом  - ничего )
нет конечно я понимаю что тут апи тормозит но из графиков этого не понять

ну покажите картинку с  бакетами
если у вас есть нормальные требования к сервисам, то у вас есть трешхолды для бакетов
и по ним будет убывает ли "зеленая полоса"

мы видим потолки границ но где тусит основной поток запросов визуально мы не видим а на конфернции ребята показывали график где толпа запросов змеей извивалась по графику

А что вы хотите увидеть?) ну время ответа не из-за загрузки  cpu   в данном случае.

Может у вас 10 клиентов урл дергают и 2 из них медленные.
50 персентиль и есть по сути основная масса

тут можно понять, что у вас есть всплески по CPU которые не коррелируют с latency
значит CPU хватает
в этой картинке не хватает графика RPS как минимум

и тут видно что да, у вас приличный разбег по персентилям

значит надо разбивать по группам запросов
например по URL

да - основная масса ниже этой границы но где? мы не видим

это нагрузочное тестирование по корневому урлу

покажите хоть свои графики - может мне понятней станет

Сделайте больше бакетов если считаете этой инфы вам мало.

Не понятно чего вы хотите добиться?

Heatmap сделайте