$~/blog/laravel-api-2400ms-to-142ms
ENGINEERING · 22 / 05 / 2026

Ako sme zrýchlili Laravel API z 2.4s na 142ms (bez prepísania)

JK/9 min čítania

Klient prišiel s jednou vetou: „dashboard sa načítava večnosť". Po pripojení Sentry Performance sme videli presne, kde čas mizne — tri endpointy žrali 80 % latencie. Žiadny rewrite sme nepotrebovali.

1. Covering index namiesto N+1

Najpomalší dotaz (orders.list, 2.4s) robil sekvenčný sken nad 4 miliónmi riadkov a k tomu N+1 na vzťahoch. Pridali sme covering index, ktorý obsahuje aj stĺpce vo WHERE aj v SELECT, takže PostgreSQL číta len z indexu.

CREATE INDEX idx_orders_list
  ON orders (status, created_at DESC)
  INCLUDE (total, customer_id);

2. Redis cache s tagovaním

Dashboard metriky sa menia raz za minútu, no čítali sa pri každom requeste. Obalili sme ich do Cache::tags() s krátkym TTL a invalidáciou cez tag pri zápise. P95 na metrics endpointe spadlo z 0.9s na 40ms.

3. Queue worker pre ťažké veci

Export a prepočty sme presunuli do queue (Horizon). Request sa vráti okamžite s job ID, frontend si poll-uje stav. Užívateľ už nečaká na synchrónny 1.8s request.

Výsledok: P95 z 2.4s na 142ms, bez jedinej zmeny v doménovej logike. Lekcia — najprv meraj, potom optimalizuj.

Ďalší →RAG nad firemnou dokumentáciou — checklist, ktorý sme si zaplatili chybami

Páčil sa vám článok?

Píšeme o veciach, ktoré reálne staviame. Ak riešite niečo podobné, ozvite sa.