Aplikaciju ne treba ubrzavati prema prvoj pretpostavci, nego prema mjerenju cijelog zadatka koji korisnik pokušava dovršiti. Ako korisnik prijavi da je aplikacija spora, najprije odredite koji je tok spor, koliko traje u početnom stanju, gdje se vrijeme troši i koju ispravnost promjena ne smije narušiti. Tek tada optimizacija performansi aplikacije postaje kontroliran posao, a ne niz nasumičnih zahvata.
Izjava da je aplikacija spora važan je signal, ali nije dovoljno precizan tehnički zadatak. Može značiti spor prvi prikaz stranice, spremanje dokumenta, pretragu, izradu izvještaja ili cijeli radni dan sastavljen od mnogo kratkih čekanja. Ti problemi mogu imati različite uzroke i različite poslovne posljedice.
Spor izvještaj može odgoditi odluku. Sporo spremanje dokumenta može navesti korisnika da ponovno klikne istu radnju. Nekoliko kratkih zastoja u svakom koraku može prekinuti koncentraciju u procesu obrade narudžbi, skladišnih promjena ili računovodstvenih evidencija. Zato korisnički simptom treba povezati s mjerljivim tokom rada.
Baseline je početno, ponovljivo mjerenje prije promjene. Bez njega ne možete pouzdano dokazati je li promjena ubrzala posao ili je samo pomaknula čekanje u drugi dio sustava.
Odaberite jedan konkretan scenarij i opišite ga dovoljno precizno da ga drugi član tima može ponoviti. Zabilježite:
Ne mjerite samo jedan endpoint ako korisnik za dovršetak zadatka mora čekati učitavanje sučelja, više API poziva, obradu u pregledniku i potvrdu spremanja. Izolirani upit može postati brži, a cijeli zadatak ostati isti zbog drugog uskog grla.
Korisno pitanje nije možemo li ovo ubrzati, nego koji dio vremena kontroliramo i koji je rezultat korisniku potreban za nastavak rada. Taj odgovor pomaže razlikovati problem infrastrukture, baze, integracije, korisničkog sučelja ili samog poslovnog toka.
Performance profiling služi za potvrdu uzroka, a ne za potvrdu početne sumnje. Zahtjev često prolazi kroz više slojeva: klijentsku aplikaciju, API, poslovnu logiku, bazu, cache, red poruka i vanjsku uslugu. Mjerenje treba pratiti taj put.
Trace može pokazati koliko je vremena zahtjev proveo u svakom sloju. Profiliranje koda pokazuje gdje aplikacija troši CPU ili memoriju. Plan izvršavanja upita pokazuje kako baza stvarno dohvaća i obrađuje podatke. Metrike reda mogu pokazati čeka li posao na obradu, dok zapisi pogrešaka i vremenskih ograničenja otkrivaju prekide koje prosječna latencija može sakriti.
Nemojte optimizirati prvu sumnju. Ako je pretraga spora, uzrok nije nužno baza. Možda aplikacija prenosi previše podataka, preglednik skupo obrađuje rezultat ili vanjska usluga blokira nastavak toka. Svaku hipotezu potvrdite metrikom koja može pokazati promjenu prije i poslije zahvata.
Česti uzroci i mogući zahvati uključuju:
Ovo nisu univerzalni recepti. Indeks može ubrzati čitanje, ali povećati trošak upisa i zauzeti prostor. Cache može smanjiti opterećenje, ali može vratiti zastarjeli podatak. Asinkrona obrada može osloboditi korisnički zahtjev, ali mijenja očekivanje korisnika i zahtijeva jasan prikaz stanja obrade.
Brži rezultat koji povremeno prikazuje pogrešno stanje nije poboljšanje. Nakon svake optimizacije provjerite poslovne invarijante, prava pristupa, redoslijed događaja i ponašanje pri ponavljanju iste radnje.
To je posebno važno u financijskim i skladišnim procesima. Promjena zaključavanja, redoslijeda obrade ili razine konzistencije može ubrzati testni scenarij, a zatim uvesti rijetku pogrešku koju je teško reproducirati. Posljedica može biti pogrešan izračun, dvostruka obrada ili prikaz stanja koje nije usklađeno s dovršenim poslovnim događajem.
Prije promjene zapišite što mora ostati točno. To može biti jedinstvenost dokumenta, raspoloživost zalihe, redoslijed knjiženja, vidljivost podataka prema ovlastima ili sigurno ponavljanje zahtjeva nakon prekida veze. Ta zaštita nije dodatak performansama. Ona određuje je li optimizacija prihvatljiva.
Jednostavan zapis smanjuje rizik da velik paket promjena prikrije stvarni uzrok poboljšanja. Za svaku promjenu zabilježite sljedeće:
Jedna hipoteza po promjeni olakšava učenje. Ako istodobno dodate indeks, promijenite cache i preradite API odgovor, možda ćete dobiti bolji rezultat, ali nećete znati koja je odluka pomogla ni koju promjenu možete sigurno ponoviti drugdje.
Kada ubrzate važan tok, sačuvajte scenarij, skup podataka i prag koji je za taj tok prihvatljiv. Regresijski test performansi ne mora se pokretati pri svakom commitu. Može biti dio provjere prije rizične promjene, većeg izdanja ili promjene integracije.
Prag treba tumačiti u kontekstu. Razlike u okruženju, opterećenju i dostupnosti vanjskih usluga mogu utjecati na rezultat. Zato je korisnije pratiti ponovljiva mjerenja i trend nego jednu vrijednost promatrati kao apsolutnu istinu.
Observability zatvara krug nakon izdanja. Testni podaci ne mogu potpuno opisati stvaran promet, ponašanje korisnika ni raspodjelu podatkovnih volumena u produkciji. Pratite trajanje važnih tokova, stope pogreške, zasićenost resursa i promjene kroz vrijeme. Upozorenje treba pomoći timu da istraži odstupanje prije nego korisnici ponovno postanu mjerni alat.
Serverska latencija nije cijelo iskustvo. Velik JavaScript paket, blokirano iscrtavanje, previše zahtjeva i skupa obrada u pregledniku mogu usporiti zadatak čak i kada je API brz.
Za dulje operacije prikažite korisniku da je obrada pokrenuta, što se trenutačno događa i kada može očekivati sljedeći korak. Time smanjujete vjerojatnost dvostrukog pokretanja iste radnje. Ako rezultat može stići postupno, prvo prikažite dovoljno informacija da korisnik može nastaviti rad.
Optimistic update ima smisla samo kada je povrat lako razumljiv i siguran. Ako se promjena kasnije odbije ili izmijeni, sučelje mora jasno prikazati stvarno stanje i omogućiti korisniku sljedeću ispravnu radnju.
Ponekad najveće poboljšanje ne dolazi iz koda nego iz promjene toka rada. Možete smanjiti broj uzastopnih koraka, unaprijed dohvatiti poznate podatke ili paralelno izvesti provjeru koja ne ovisi o prethodnom rezultatu. Takva odluka zahtijeva razgovor s vlasnikom procesa, osobito kada aplikacija povezuje više poslovnih modula povezanih s ERP-om .
Prije sljedeće optimizacije zapišite stvarni korisnički zadatak, početno vrijeme, najsporiji potvrđeni korak i način na koji ćete dokazati trajnost promjene. Zatim odaberite jednu hipotezu, izmjerite učinak i provjerite zaštitne uvjete.
Ako sporost proizlazi iz nejasnog prijenosa podataka između procesa, problem možda nije samo tehnički. ERP i procesni screening može pomoći strukturirati tok, ovisnosti i točke mjerenja prije većeg zahvata. Korisnik ne osjeća pojedini endpoint. Osjeća koliko je puta čekao i može li dovršiti posao bez prekida koncentracije.