Nie zgaduj — najpierw zmierz. Powolność może pochodzić z klienta, sieci, serwera lub bazy danych. Metodyczne podejście znajduje gdzie trafia czas, a następnie naprawia największego sprawcę zamiast optymalizować losowo.
Nie zgaduj — najpierw zmierz. Powolność może pochodzić z klienta, sieci, serwera lub bazy danych. Metodyczne podejście znajduje gdzie trafia czas, a następnie naprawia największego sprawcę zamiast optymalizować losowo.
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
Użyj karty Network/Performance przeglądarki i timing serwera, aby podzielić całość. Przydatny podział:
Total 1200ms =
DNS/connect 20ms
server TTFB 900ms ← the bottleneck is server-side
download 80ms
client render 200ms
Spojrz na percentyle, nie średnie: p50 (typowy użytkownik) kontra p99 (najgorszy przypadek). Szybkie p50 z powolnym p99 wskazuje na okazjonalne problemy — lock contention, zimne cache'e, powolną replikę DB lub GC pauses — nie uniformny problem.
Narzędzia APM (traces) pokazują dokładnie, gdzie trafia czas w żądaniu:
GET /orders 950ms
├─ auth check 10ms
├─ SELECT orders 30ms
└─ loop: SELECT user per order 900ms ← N+1 query, the real cause
Slad wskazuje bezpośrednio na winne wezwanie. Następnie sprawdź ostatnie zmiany — wdrożenie, brakujący index lub wzrost danych 10x często wyjaśniają nagłą regresję.
Dgadywanie marnuje godziny na optymalizowaniu niewłaściwej warstwy. Najpierw pomiar, śledzenie powolnego spanu i przejrzenie p50 kontra p99 zmienia niejasne "to jest wolne" na konkretną, naprawialną przyczynę — a ponowny pomiar dowodzi, że naprawa faktycznie zadziałała.
Biblioteka pytań rekrutacyjnych IT ze szczegółowymi odpowiedziami — od Juniora do Seniora.
Wesprzyj