За межамі P95: выкліканне затрымкі, якія насправды перажываюць вашы корыстувальнікі

Адзёнак паведамляе, што прылада работае медленна. Хтось ачынае панель картоў з метрамі запазджэння, і там усё зеленае: P95 на роўні цялевага показніка, штоць бягаўых канфліктавання стабільны, CPU працуе з мінімальны навантажэнням, колькасць з’яўленняў да базы дадзенаў значна нижэй за ліміт. Пастойны вывад — што жалоба павінна быць некоректная, і гэты інстынкт, які даўае перавагу графіку над чалавекам, які проста чакаў, ёсць справжнія проблема.

У наступных раздзелах пояснюецца, чаму адночасна можа быць і стабільны показнік P95, і медленная прылада. Вы зрозумеўце, дзе запазджэння заховваецца ад метрагаў роботы службы (чэргі, пракушанні, розпад задаў, блакування рашэнняў), чаму „хвост“ показніка мае большое значэнне, чым можна было б спадзявацца на паўголасы ўжо за його розмерам, і як простая прычынка — звяртанне ўвагі на час адбыцца кожнага крока запросу — ператварае нечыясныя жалобы на практычныя доказы. Да канца вы зможаце практычна ставіць пад сумнев тверджэння „P95 ў порядку“, замест таго, каб або яго прийняць, або адхіліць.

Што паведамляе і чаго не паведамляе P95

Цікава будзе даклэгае точна інформацыя пры крітыкаванні гэтаго показніка. P95 — это значэнне, пры яком чыраці па 95 процэнтаў запытанняў было завершана. Это сапраўдзіцца корыстны показнік, і ён значна кращы за сярэднюю затрымку. Сярэдняе значэнне — гэта там, дзе зникаюць усі проблемы ў рэальных умовах: якщо дзевяносто дзевяць запытанняў завершаюцца за 50 мс, а адна — за пяць секунд, то сярэднее значэнне будзе апошней прыбліжна 100 мс, і ніхто не будзе на гэта звяртаць увагу. Перцентыль прынеймна спрывае вашу увагу да краяў распаду данных.

Таму сам пярцэнтайл не ўтварае проблемы. Проблема — у ролі, яю каманды яму надаюць пасля його аналізу. Фраза «P95 ў порядку» часта выступае як свідчэнне невіны, яке завершае дыялог. Такой падход тыхо забывае пра асновную рэч: ніхто з тых, хто викорыстоўвае ваш продукт, не спрыямацца пярцэнтайламі. Люди спрыявацацца чаканнем. Апускаючы кран, яны спрабуюць з’ясавіць, чыя гэта дзеянне было зафіксавана. Яны бачаць сторунку, якая выглядае так, нібы ўжо адрасавана, але не рэагуе. Яны спаглядаюць індыкатор загрузкі, пакуль калькольныя службы, якія працуюць у спіну, кожна падае абсалютна разумныя цифры.

API можа мець выдатны показнік P95, тады як продукт, створаны на його аднойчыне, можа здацца важкім у викорыстоўванні. Адразу врахаваць оба этых факты — гэта выйсковая пункт для всьога, што будзе далей.

Кожны запит адбываецца пад наглядам трох прыбораў

У большасці дыялогаў пра затрымкі прыпускаецца наявнасць адного прыбора. У практыцы іх ёсць як мінімум трох, і яны вимерваюць розныя показнікі.

• Часы сервера. Прыходзіць запит да вашага сервісу, выходзіць адпаведны адказ, тады стойка часу зупіняецца. Гэта тое, што паказуюць большасць панелей керування бэкендам.
• Часы залежнасцяў. У момент запиту і ў яго абліку час выкорыстоўваецца на аутентыкацію, чаканне на з’яўленне канектыва да базы дадзенаў, внутршніе HTTP-званні, недаступнасць кэша, праказы, адкладанні задач, перагляд флажакаў функцый, API трэціх сторон і ўсе компаненты, якія "зазвичай працуюць быстра"
• Часы чалавека. Пользователь нажаў, потым чакаў, і толькі пасля чаго экран стаў прыдатным для вжывання. Гэты єдины періяд, які цікавіць пользователя.

Команды звычайна спачатку оптымізуюць час адпаведнага процесу, а пасля описваюць продукт як быстры. На адным з дыяграмаў паказаны тры варыянты разам: сервіс показвае час адпаведзення у розмяре 180 мс, тады як ланцуг залежнасцяў уключае пракату ў розмяре 600 мс, а чалавек за клавіатурой яшчэ спытаецца, чаму сторана не завантажваецца.

SERVER CLOCK

request in  ------------------------------> response out
              "API P95: 180ms"

DEPENDENCY CLOCK
request in  ---> auth ---> db ---> service A ---> retry ---> service B ---> response out
                 40ms    70ms      120ms        600ms       90ms

HUMAN CLOCK
click  ----------------------------------------------------------------> usable screen
       "Why is this still loading?"

Нічога на серверскам гадзіку некоректна. Ён проста неўжывочны. Ацэнка швальнасці продукту на ўзгляд гадзіка падобнае да зьвяршэння перамеру температуры чалавека і стварэння вражэння, што всі органы здаровыя: інодзе самэ гэта значэння є важлівым, а інодзе яно не паказвае рэальную проблему.

Канцэнтры падключэння — гэта дзверы, а парадокс корыстнага викорыстання — гэта будынак

Корыстны ментальны модэль: канцэнтра падключэння на бэкендзе — гэта адна дзверы, тады як парадокс корыстнага викорыстання — гэта праход чрез цэлы будынак. Дашборды пераважна вимерваюць канцэнтры падключэння. Увайшае запит, выходзіць адпаведнае адпаведзенне, графік апошней часу адбываецца, і всі расслабляюцца.

Адзінакі ж не прыходзяць там, каб маравіцца дверзямі. Яны хочуць досягнуць паказанага цялі: ачыць галоўны экран, адправіць платеж, зробіць замовленне, завантажыць выкладку, адмахнуцца ад адной рэальнай задачы, не відчуваючы, што прылад вагаецца з рашэнням. Гэта задача рэдкая разоў падпадае пад адзін выклік сервера. Ачыць панель керування ў типовым додатку з адной сторанай больш супамінае процес, паказанный нижэй, калі прылад спачатку запрашае інфармацыю пра профіль, правыя, рахункі, прыемліванні, паведамленні і ліміты, перш чым з’являецца ўжо якаясь корисная інфармацыя.

User Clicks "Open Dashboard"
        |
        v
+----------------------+
| Frontend Shell       |
+----------------------+
        |
        +------> GET /profile
        |
        +------> GET /permissions
        |
        +------> GET /accounts
        |
        +------> GET /offers
        |
        +------> GET /notifications
        |
        +------> GET /limits
        |
        v
Screen Finally Becomes Useful

Кожны з тых шасо канцэнтраў можа выглядаць стабільным па самастойнай лініі, тады як вялікае цэлае раштрыненне выглядае несправным. Сэрвіс можа выпалняць сваеяя SLA і ў той жытак спадчыцаваць медленнае працэўніцтва продукту. Команда можа досягнуць своих цэлей і ў той жытак пагіршыць якасць адносін з корыстувальнікамі. Калі запыты выкананыя абоўязкова па рэчы, іх затрымкі сумуюцца; калі ж яны выкананыя паралельна, наймедленнейшы запыт задае тэнпас, а ліміты з’яўленняя канектацый браузера да кожнага выхаднага пункту або залежнасці між запытамі можу прывести да таго, што робота, якую вы супакоўваліся, што яна будзе паралельная, на самай працэ практычна будзе выкананая абоўязкова па рэчы.

Саме таму фраза "наш API ўсё ж быстрый" являецца толькі пачаткам расследавання, а не восьпамкай. Наступныя запытанні ўскладненыя, але неабходныя: быстрый у пораўнанні з чым, для каго быстрый і з якога моманту вимерваецца быстрыня? У межах вашага сэрвісу чы з моманту, калі корыстувальнік нажаў кнопку?

Рэшта пяць процэнтав — гэта не памылка аброунавання

Назва „P95“ дае враку, што проблема незначная. Пяць процэнта здаецца прыемным костам роботы у масштабе, такім, які можа пераканаць спокойны камітэт з аналізу данных.

Але трэба врачыць рэальны обсяг. Система, якая обрабоцвае мільйон запитоў на дзень з прагамай P95, кожны дзень мае пяцьдесят тысяч запитоў, якія перавышаюць гэтую прагу. Кожны з іх — это момент, калі хтось можа зноў нажыць на кнопку, апавярніць сторанку чы проста заўсёды пакінуць процес і зваліць віну на продукт.

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

• Одні нешчасны корыстувачы можаць практычна ўсё час трапляцца на повольны шлях обробкі.
• Одні корпоратыўныя кліенты можаць застряць на перавантажанай частцы системы.
• Одны регіон можа паспрабаваць занізіць карыстнае якосць, тады как загальны показнік за глобам застаецца прыемным.
• Высокая за цэнай рабочы процес можа быць повольным, тады как дешавыя, частыя запиты дапамагаюць падтрымваць прыемны показнік у відсотках.

На панелі керування адміністраторы бачаюць паведамленні пра абраныя дастаткі. Адмініструемы корыстувач перасягае якісь асобістыя проблемы. З точкі зору системы частка запытак была повольная; аднойчы з точкі зору корыстувача продукт проста пераспяліў яго час.

Самэй гэтага скаргі корыстувачаў трэба спрыяваць як дадзеныя. Люди не абвешчаюць пра проблемы па відсотках; яны абвешчаюць пра іх у вастрых прыкладах. «Кожны раз пасля натыскання кнопкі „Адправіць“ система застоюецца». «Старонка паказваецца, але цифры прыходзяць пазней». «Мне трэба два разы перзагружаць старонку». «Всё працуе, але ўсё равна дзіўна повольна». Ні аднаго з гэтых прыкладаў ня ёсць расплывчатым. Кожны з іх — гэта атрыбуты карыстоўнай якосці, напісаныя простаю мовай, а загальная проблема — гэта пераклад іх у неправія показнікі і выварышчанне, што нічога не ёсць не так.

Два сервісы, адна вялічына P95, чыразны рызык

Адзін пярцэнтайл нічога не сказвае пра форму распаду абоўшчынай яго. Разглядзім два сервісы з падобным значэнням P95. Першы не выдзеляецца: большасць запитоў є сярэдніх, медленныя запиты проста трохі медленнейшыя, і немае рэзкаг перападу. Другі большую частку часу працюе быстро, але часамі ўпадае да рэгіону колькісці зусім у кантэксте калькуляцый у канцэ хвілін.

SERVICE A

Most Requests        120ms - 260ms
Slow Requests        300ms - 380ms
Disaster Requests    Rare

SERVICE B

Most Requests        40ms - 80ms
Slow Requests        300ms
Disaster Requests    8s - 12s

Оба можу паказваць прыбліжна адно і тое ж значэння P95. Толькі Сервіс B мае „падводную дзверцяту“, якая знаходзіцца цэлкам за межамі 95-го пярцэнтайла, таму дакладныя даны не можа яго пазіраць. Толькі аналіз значэння P99, P99.9 і максымальных значэнь, або ж візуалізацыя у вачынку гістаграмы або тэпловай карты, можа адкрываць гэтую разніцу.

Пярцэнтайл таксама не паказвае, дзе концентруецца бол. Ён не сказае вам, чыя це спадзейны запиты: аднае ўтрэмліцы, адной канцэнтры, аднай часткі базы дадзеных, адной залежнасці нижэй у ланцузе, аднай регіёна, адной дорагі перапрыбутку, аднай заполненай пулі нитак, чыи то функцыі, якія выконваюцца толькі пад час важных дэманстрацый. Разбіўка затрымкі па гэтых параметрах ператварае цяжэлы чысла ў діагназу.

Практычная правіла: панелі керування на адной пярцэнтайле должны запускать дыялог, а не заканчваць яго. Пытанне не толькі „Калі ёсць наш P95?“, але і „Які бол стоіць за гэтым чыслам?“

Найбольшыя затрымкі існуюць между камандамі

Дзеянне дэйлейт-проблем некалькіх разоў ёсць майже прыемным, таму што прычына іх ўсведамлена. Павольны запит атрымвае індэкс; якшто не хапае кэшу, ён адбываецца з асторожнасцю; занадта вялікі пакет дадзеных скарацваецца; неэфектыўны цыкл перапісваецца. Усі розумяюць гэта.

А болючыя проблемы з’яўляюцца ў праслойках між камандамі. Бэкенд паведамляе, што API працуе нормальна; фронтэнд — што чакае на бэкенд; платформа — што гейтвей працуе адлічна; каманда з базай дадзеных — што база дадзеных у порядку; продакт — што корыстувальнікі яшчэ незадоволеныя. Кожны з іх кажа правду, і гэта самое робіць ситуацыю такой разчароўваючай.

У такіх случаях система не ўповольняецца ні в аднам явным месцы. Яна уповольняецца ў «шваях»:

• пры перадачы дадзеных між службамі;
• пры павторным запытанні, якое подвойвае трываласць вызову;
• пры другім запытанні, якое ніколі не трэба было выканаць;

падзе ў перакананні пра правы на выконанне задачы, якае адбываецца пасля таго, як важкая робота ўжо запусцілася;

падзе ў немагчымасці знайсці даныя в кэшы, якая застаецца непазначанай, таму што процес доўжыні адпаведзення заставаецца меньшым за норматывны ліміт;

падзе ў службе трэціх сторон, якую всі называюць „зовнішняя залежнасць“, ўжо таму, што гэта звучыць менш некомфортна, чым адзначыць, што гэта ўжо часть корыстнікаўскага досвяду;

падзе ў черге, яшчэ перш чым запускаецца ваш пат кода;

падзе ў серыялізацыі, пасля таго, як завершылася бізнес-логіка;

на фронтэндзе, таму што API вернуў даныя, створаныя для базы дадзенаў, а не для экрана, і кліенту трэба яе перзбіраць занова.

P95 не падвела нікога, будучы некалькаватай. Яна падвела таму, што была адособленая. Адособленае показніця дазволяе кожной командзе падтвердзіць свою невінаватасць, пакуль корыстнік продовжае чакаць.

Час, прабыты ў черзе, яшчэ ўважаецца затрымкай

Існуе ўзьменейшы проблема з мераванням: таймеры на рэвэлі аплякацый часта запускаюцца занадта пазно. Калі ваш хэндлер або кантролер пачынае выконвацыю, запит можа ўжо працаваць у стане чакання на балансэры навантажэння, чакаючы на з’яўленне канектаціі, чакаючы на рабочы процэс або нить, або чакаючы пасля іншых задач, таму што процэс тэхнічна быў запусканы, але фактычна перавантажаны. У Node.js той самы эфект выражаецца як затрымка ціклу адбывання падзеяў: актыўны цікл означае, што калбэкі, уключаючы ваш хэндлер запита, пачынаюцца пазней, чым сокет прымае даны.

Потым запускаецца ваш таймер, код выконваецца быстра, і паметры фіксуюць шырокі запит. Корыстніку не важна, дзе была межа вашага стоп-часу — чаканне да пачатку таймера таксама лягае ў вазу. Так сама, як і чаканне падчас перапрыбуткаў, чаканне на наступны неабходны вызов з боку браузера і чаканне, пакуль аблікованая кнопка стане доступной для натыкання.

Это ўловак межаў зьвярнень. Команды вимерваюць тое, што можа быць зафіксавана ўхіднай службай, а потым неявнаа прыймаюць усё, што знаходзіцца за межамы гэтага абзору, за неіснуючае. Затрымка, якую нельга побачыць, не ёсьць уявной; гэта затрымка, за якую ніхто не несе адпаведнасьці, і такая затрымка часта ёсьць найдорожэйшай, таму што ніхто не абавяжаны яе зменшваць. Часы обробкі запитоў балансэра навантажэння, показатэлі чакань у басе з’ўязкаў, запазджэння ў цыкле адбывань надзяй і часы на боку прыгледчыка — гэта звычныя способы, якімі можна практычна побачыць гэтыя інтэвалы.

Называнне кожнага крока запиту

Тое, што зазвычай раз’ясняе гэтыя споры, — не яшчэ адны панелі керавань, новы постаўчык або большы бюджет на стварэнне можлівасьця абзору. Гэта з’явленне можлівасьці сховаць повольную частку запиту, даваючы кожнай яго частцы чыстую, адкрытую назыву.

Наведзены выклік — это хэндлер у Java на базе Spring Boot, але такі патэрны можна без прыбліжэння перадаць у Express, Fastify чытаў NestJS. Для запиту GET /home пачынаецца обработка LatencyTrace, якая прыўязваецца да заголовка X-Request-Id. Кожны значымы крок — загрузка даных аб корыстніку, запрашэнне прав, вызов служб з утриманням рахункоў і прысутнасцю прадстаў, а таксама форматаванне адповедзі — абгорнуты ў trace.time(...) з описавальным пазначэнням. У блоке finally выконваецца trace.logIfTotalCrosses(Duration.ofMillis(700)), які фіксуе деталі толькі калі час адпаведзі на весь запит перасягае 700 мс; таким чынам, для нормальных запытоў лог залишаецца тыхім, а для повольных — мае деталізаваны твор. Точная рэалізацыя мае меншое значэнне, чым прычынка, яку ёй даўце.

@GetMapping("/home")
public HomeResponse home(@RequestHeader("X-Request-Id") String requestId) {
    LatencyTrace trace = LatencyTrace.start("GET /home", requestId);
try {
        User user = trace.time("db.user", () ->
            userRepository.findActiveUser()
        );
        Permissions permissions = trace.time("auth.permissions", () ->
            permissionClient.fetch(user.id())
        );
        List<Account> accounts = trace.time("accounts.http", () ->
            accountClient.fetchAccounts(user.id())
        );
        List<Offer> offers = trace.time("offers.http", () ->
            offerClient.fetchEligibleOffers(user.id())
        );
        return trace.time("response.mapping", () ->
            HomeResponse.from(user, permissions, accounts, offers)
        );
    } finally {
        trace.logIfTotalCrosses(Duration.ofMillis(700));
    }
}

Є два моменты, якія вартае звернуць увагу. Перша — ключоўка finally гарантуе, што будзе зафіксавана інформацыя пра абранне, нават калі ў якомні з крокаў выйдзе памылка, і самэ гэта ёсць тады, калі гэта найбольш неабходна. Друга — крокі тут выконваюцца адны за іншым, таму загальны час приблізна доравняе суме ўсіх крокаў; якщо паралелізаваць незалежныя запыты, такія як абліквы і працэсы з прадуктамі, то система все раве должна відлічваць час кожнага з іх, ўбачыць, калі самэ гэты крок вплывае на загальны час.

Порашчыце тое, што дае звычайны лог часу адпаведзення, з тым, што дае гэты спосаб. У звычайнай версіи ёсць адна лінія з загальным часам:

GET /home took 1180ms

Гэта точна, але практычна безпарацейна, таму што не сказвае нічога пра тое, куды пайшло 1 180 мс. Версія з деталізацыей крокаў адразу на гэта адпавядае:

GET /home took 1180ms

db.user              42ms
auth.permissions     81ms
accounts.http        156ms
offers.http          823ms
response.mapping     28ms

Калі такі даныя практыкуецца пры обсужэнні, тон розмовы зменшаецца. Няхто не павінен здагадватыся чырагаць свойяй службе, а фраза «у мяне все працуе» больш не ўважаецца значымым аргументам. Прыблізна 70 процэнтавах запыткаў стосуецца пропантаў, таму розмова пераходзіць з адгукаванняў на доказы. Гэта і є справжнія выгода ад хорашага інструментарыю: не больш графікаў, а менш спораў.

У базе коду Node.js можна парадоксальны спосабом досягнуць таго жа рэзультата, выкарыстоўваючы performance.now() пры кожным запрашэнні, якое чакае на адпаведны рэсультат, і структураваны логгер, але болей систематычна — за дапамогою OpenTelemetry spans, якія парадынальваюць назвы крокаў за межамі служб, так што аналіз застаецца актуальным, калі повольны крок знаходзіцца ў чыёй-небудзь іншай службе. Для болей шырокага розгляду способаў сумешчання логаў, метрык і трэйсоў, адзірніце статыю пра стварэнне observable Node.js API.

Чаму чыстыя тэсты на выдатнасць можаюць практычна апрацаваць хаотычную систему

Сюды зазвычай у аналізах выдатнасці дадаёцца табелі з рэзультатамі тэстаў. Але ёсць важлівая прычына не робіць гэтага тут. Тэсты на выдатнасць є ценнымі, калі яны адпаведны рэальнасці, але вымышлены тэст для гэтай проблемы будзе проста ўсё таму ж самым, але пад маскай формальнасці.

Проблема не ў тым, што інжынеры не можуць адрабатваць кантролюемыя тэсты. Проблема ў тым, што кантролюемыя тэсты часта адключаюць саме тые факторы, якія заважаюць корыстувачам:

• Бенчмарк працюе з адним канцэнтрам; рэальныя дзеяння корыстувача запускаюць многія з іх.
• Бенчмарк адбываецца з запрацоўванымі кэшамі; корыстувачы з’яўляюцца пасля разгружэння, выкарыстоўвання іншых рашэнняў і працы з кодам у стане «холадны».
• Бенчмарк мерыць успешныя адпаведзі; корыстувачы сталкваюцца з частячнымі неудачамі, павторнымі спробамі, тайма-аутамі і недзейнаючымі экранамі.
• Бенчмарк прыпускае стабільныя залежнасці; у рэальных умовах залежнасці застаюць стабільнымі толькі пакуль гэта можліва.
• Бенчмарк ізолюе адну службу; тое, з чым сталкваецца корыстувач, складаецца з многіх служб, а таксама браузераў, сетей, очакваннях, угодах API і рашэннях каманд, якія можа ўжо не спілкуюцца межы сабой.

Бенчмарк паказвае, насколькі шырока можа быць швайная дорага. Продукт паказвае, насколькі чысты ўсі система. Это разныя памеры, і адні не можу заменіць другія.

Швайны код не гарантуе швайнага продукту

Большасць інжынераў, якія працуюць з бэкендам, абавязкова стараюцца прыняць локальныя оптымізацыі. Вы зменшуеце час выканання функцыі з 20 мс да 8 мс, удаляеце некалькі элементаў, перастраюеце цыклы, налаштовуеце запиты, і всё здаецца ідеальным. Аднак продукт все ўсё чакае на удаленную службу, якая на кожны дзесяты запит выканана за 900 мс. Экран все ўсё дзейнае занадта дуго, кнапкі все ўсё застойваюцца, а запыты на падтрымку продаваліяць як «сповольненыя».

Это як поліруванне латуні, калі падае сам паркет. Работа на местным рынку прывабліва, таму што вона цалком пад вашым контролем. Затрымка на всіх етапах є складнейшай, таму што для яе падборкі трэба прымкнуць іншыя каманды, вжываць старыя контракты, выбіраць продукты та архітектуру, якую ніхто не хоча перазглядаць. Аднак корыстувачы не награджаюць місцевую элегантнасць; яны награджаюць завершаныя дзеяння. Швайная функцыя — гарна, швайны канець-пункт — яшчэ кращы, а швайны процес — гэта тое, што насправды мае значэння. Перш чым оптымаціраваць будзь-які окремы компонент, корисна пераканацца, што ён знаходзіцца на критычным маршруце процесу, які каго-то цікавіць.

Калі найпамедлейшая залежнасць — это рашэнне

Не кожная проблема з затрымкай є тэхнічной. Дзеякія з іх — это рашэнні, якія сталі частью архітектуры:

• Фронтэнд вызывае шасць API, калі дапрацоўваць адно агрэгаванае адпаведзенне было б даскладней.

Кожны экран занова запрашывае службу дазвола, узаменяючы яе рэзультатамі.

Прабавы падаюць сінхронна ў маршруцы запита, які бачыць корыстнік.

Віджэт з працоўнымі прапанунамі блакуе атрыбутаванне всього галоўнага экрана.

Падзеі аналітыкі павінны выконвацца раней, чым корыстніку будзе разрэшана працэсаваць далей.

API вяртае об’екты, схожыя на базу дадзеных, і залічвае фронтэнду сформаваць значэнне з іх.

Служба, якая працуе пасля іншых, атрыбутаваная як "карытатэйна", таму што ніхто не хацеў сказаць, што ёё функцыя можа быць завантажаная пазней.

Спадзейшыя часткі системы часта являюцься наследкам выбору продукту, які ніколі не аналізався, прычынай у спадкуванні прав на ўтриманне, або зустрэчаў, якія адбыліся давно і чыя наследкі сталі пастойным затрымленнем. Для багаторых з гэтых проблем існуюць вядомыя способы рашэння, такія як викорыстанне бэкенду для фронтэнда, який агрегуе запыты, паслядовая або відкладаная загрузка неканцэсарных элементаў, перанесення спроб падключэння і аналітыкі за межы критычнага шляху, а таксама форматаванне адпаведных адказоў пад параметры экрана. Аднак кожны з гэтых спосабоў выклікае патрэбу, каб хтось мяў права на зміну рашэння.

Самэ гэтая прычына змушвае роботу над паўнэчаснасцю ставаць політычной, калі вядомыя способы рашэння вжываюцца. Чыстае затрымленне тады стае пытаннем адпаведнасці. Хто мае право прызначыць якую-небудзь залежнасць обавязковай? Хто несе адпаведнасць за весь процес? Хто мае права адмовіць у запыте? Хто несе адпаведнасць, калі всі сервісы працуюць нормальна, а якасць ўсё равно падлегла? Показнік P95 не можа даць адказа на жадна з гэтых пытанняў, і ён ніколі не быў створаны для гэтага.

Зеленыя панелі керування можаць зменшыць цікавасць каманд

Менш прагматычны факт: зеленая панель керування можаць заставіць каманду перастаць ставіць запытанні. Не завжды, але достатна часта колькасць, каб гэта мела значэнне. Калі графік становіцься чырвоным, усе прачынаюць расследаванне. Калі графік зелены, а корыстнік скаржыцца, размова прагне да таго, каб скаргу адхіліць. Можа, у ягоў сет быў паслаблены. Можа, ягоў браузер быў повольны. Можа, гэта было ентычнае явісце, але падтрымка перэценіла ситуацыю, але фронтэнд зрабіў штосьц незвычайнае, але кліент нажаў занадта рано, але скарга ёсць эмачная, а не тэхнічная.

Саме так каманды втрачаюць довер'е — не чераз нехватку дадзэнняў, а через тое, што выкарыстоўваюць дадзэнні як прычыну не слухаць. Корыстнік не мае вашай панелі керування; ён мае ваш прылад. Якщо для ягоў ён здаецца повольным, гэта є доказ. Гэты не ўсёвыплнены чы ідеальны доказ, але гэта ўсё-такі доказ.

Здаровая інжынярная культура спрытвае графік як аднаго свядка, а пользователя — як іншага, пры чым процес вырабаткі ўважаецца местам дакладнага аналізу. Культура, якая спрытвае графікі як правду, а пользователяў — як шум, прыводзіць да таго, што продукты выпускаюцца медленна, хоча ўчасці ўсё ж такі спадзяюцца, што яны працуюць быстра.

Пачніце з таго, што прабаваў зробіць пользователя

Дыскусіі пра выдатнасць зазвычай арганізуюцца навакола складовых: який сервіс, які канец-пункт, якае запытанне ўсё гэта медленна. Це хорашыя запытанні, але яны рэдка калі ёсць найкращымі першымі запытаннямі. Кращы пачатак — гэта: што прабаваў здарыць пользователя? Калі вы на гэта адпавісіце, зазвычай сама сабою выйдзе правильная метраклія:

• Для ачынення панелі керування — меркайце час ад моменту пачатку да момента, калі панель справа ўжо гатовая да выкарыстоўвання.
• Для адправкі формы — меркайце час ад моменту адправкі да момента, калі з’яўляецца візуальная парадактка.
• Для завантажэння звіту — меркайце час ад кліку да момента, калі файл стае доступным.

Для выліку неабяжна мерыць ад пачатку да фінальнага стану з вылікамі.

Гэта здаецца бяспрэчным, але багатыя системы не працуюць такім чынам. Їх аналізуецца па межах каманд, таму што так проста стварыць інструменты для мэтраграфіі та атрыбутыўныя панелі з дакладнай інфармацыей. Аналіз процесаў, якія відбываюцца ў рамках аплынку, є сложнейшы, і яны даюць менш практычныя рэзультаты, пры чым саме гэтыя менш практычныя рэзультаты стаюць адной з прычын паследовных практычных улучшэнняў продукту. З боку кліента, API прыгледачаў, такіх як інтерфейсы Performance та User Timing, дазволяюць чытка пазначыць моменты „па клацанні корыстувальніка“ та „доступнасць экрана“, а сувязаванне гэтых пазначэнняў з ID запиту дапамагае прыўязаць часовыя показнікі корыстувальніка да логаў сервера. Якщо выявіцца, што спад працызледжання стоўіць у зв’язку з процесам выканання, а не з сетчатым з’єднаннем, стацыя ў діагностицы працызледжання React за межамі часу адпаведзі сервера рассказвае пра гэю сторону проблемы.

Ставіцеся да метрыках з адказной падозрою

Нічыя з гэтых пунктаў не ўтвараюць аргументу для выдалення P95 з вашых панелей керавання. Ён належыць там і мае значэнне. Проста яго не трэба спакою даваць веры. Хорашы пярцэнтайл должен прывучыць вас да большага адказу, паказваючы на запиты, якія знаходзяцца за межамі:

• Хто саме належыць да тых пяці відсоткаў з медленнымі запитамі, і чыя то завжды тыя ж людзі?
• Да калей корыстувачоў належаць гэтыя запиты?
• Чы неякая залежнасць ўсталявае большую частку проблем?
• Чы якая-небудзь адзіна рэгіон мае проблемы, калі загальная ситуацыя выглядае нормальна?
• Чы якісь конкрэтны корыстувач постаўляе найбольшыя проблемы?
• Чы практыка перапрыбутків таямна ператварае абыяковасці на дугі чаканне?
• Сколькі часу запиты працуюць у черзі, перш чым пачнёцца таймер аплікацыі?

Чы гэты стан фронтэнду заставляе экран застацца заблокаваным пасля таго, як бэкэнд вялікі ўжо адпаведзеў?

Чы якаясь служба на паперы ў стане «здаровая», але на практыцы шкодзіць продукту?

Правыя стосункі з паметрай — гэта не яе абожненне і не адхіленне. Гэта згаджаная падозра. Паметрай — гэта свядок, а свядкі могу не паведамляць важлівых детаў.

Ключовыя выводы

Апасны сцэнарый — гэта не паметрай, якая явна некоректная; такую легвае з’яўіць. Гэта паметрай, якая так абавязкова стварае вражанне маленькай правды, што всі перестаюць шукаць большую. Калі хтось знову скажае, што P95 ў порядку, не спарчуйцеся з цыфрамі; запытайце, што ў яе не ўключана. Чы ў яе ўключаны час чакання у черзі, практыкі, чаканне фронтэнду, вызов трэцьяй стороны, тое, што корыстнік нажымае кнопку знову, таму што нічога не выдзейвалася, і момент, калі экран нарэшце стаў прыдатным для выканання задачі, яку хацеў адрабаты кліент?

• P95 прыгае вышэй за сярэгу, але не паказвае форму распаду, ступень аграсывання і тых, хто падвержаецца наследкам; яго трэба адурачываць з вышэйшымі перцентылямі, гістаграмамі і разбівкамі па абонентах чыста па регіонах.
• Трэба развяжаць серверскія, залежныя і людзкія таймеры, і пераканацца, што кожны з іх мае свога адпаведальнага.
• Працэўна дорога пользователя зазвычай складаецца з многа крокаў; трэба мерыць всю дорогу, а не толькі канечныя пункты.
• Таймеры прыкладнення часта не урахоўваюць час чакання ў черзі, падключэння і затрымкі цыклу запуску задач; гэтыя элементы трэба мерыць якраз.
• Мерыленне кожнага пункту запиту і фіксаванне дэталей, калі перакрытыя прагі, заменяе акцусы на доказы.
• Часта час адкладэння ёсць наследкам рашэнняў пра продукт і адпаведальнасць, і ўсунуць яго можна толькі за дапамогай адпаведальнага чалавека, які мае право іх змяніць.
• Трэба ставіцца да прытаканняў пользователя як да атласаў эфектывнасці, а да панелей керування — як да аднаго з канстантных джэрел інфармацыі.