Älä arvaa — mittaa ensin. Hitaus voi tulla clientista, verkosta, serveristä tai tietokannasta. Menetelmällinen lähestymistapa löytää, minne aika menee, ja korjaa sitten suurimman tekijän sen sijaan että optimoisi satunnaisesti.
Älä arvaa — mittaa ensin. Hitaus voi tulla clientista, verkosta, serveristä tai tietokannasta. Menetelmällinen lähestymistapa löytää, minne aika menee, ja korjaa sitten suurimman tekijän sen sijaan että optimoisi satunnaisesti.
1. MEASURE → where is the time spent? client render, network, server, DB?
2. REPRODUCE → confirm it reliably (same endpoint, payload, user)
3. TRACE → use APM/distributed traces to find the slow span
4. CHECK RECENT CHANGES → deploys, config, traffic, data growth
5. ISOLATE → layer by layer, narrow to one component
6. FIX the biggest contributor → re-measure to confirm
Käytä selaimen Network/Performance välilehteä ja palvelimen timing-tietoja kokonaisuuden jakamiseen. Hyödyllinen erittely:
Total 1200ms =
DNS/connect 20ms
server TTFB 900ms ← the bottleneck is server-side
download 80ms
client render 200ms
Katsele prosenttipisteitä, ei keskiarvoja: p50 (tyypillinen käyttäjä) vs p99 (pahin tapaus). Nopea p50 hitaalla p99:llä osoittaa satunnaisia ongelmia — lukon kilpailua, kylmiä välimuisteja, hidasta DB-replikaa tai GC-taukoja — ei tasaista ongelmaa.
APM-työkalut (traces) näyttävät tarkalleen, minne aika menee pyynnön sisällä:
GET /orders 950ms
├─ auth check 10ms
├─ SELECT orders 30ms
└─ loop: SELECT user per order 900ms ← N+1 query, the real cause
Jäljitys osoittaa suoraan loukkaavaan kutsuun. Tarkista sitten viimeaikaisia muutoksia — käyttöönotto, puuttuva indeksi tai 10-kertainen tiedon kasvu selittävät usein äkillisen taantuman.
Arvaaminen tuhlaa tunteja väärän kerroksen optimointiin. Mittaaminen ensin, hitaan spanin jäljittäminen ja p50:n vs p99:n katsominen muuttaa epäselvän "se on hidas" konkreetiksi, korjattavaksi syyksi — ja uudelleenmittaaminen todistaa, että korjaus todella toimi.