Aplikacija je spora i korisnici se žale? Prije nego kupite jači server, pročitajte ovo
Korisnici se žale da aplikacija sporo radi, a rješenje je jači server? Obično nije. Gdje se stvarno gubi vrijeme, kako to izmjeriti i kad server ipak treba.
Vlado Pandžić · Osnivač · Senior .NET arhitekt
Objavljeno · 3 min čitanja
Korisnici se žale. Ekran se vrti, izvještaj traje dvije minute, a u ponedjeljak ujutro ništa ne radi kako treba. Netko predloži jači server ili veći paket u oblaku. Kupite ga, bude malo bolje dva mjeseca, a onda opet isto. Samo što je račun sad veći, i to svaki mjesec.
To se događa jer je jači server u većini slučajeva odgovor na krivo pitanje.
Zašto jači server rijetko rješava problem
Zamislite skladištara koji za svaki artikl s narudžbe posebno ide u skladište i vraća se. Za narudžbu od 400 artikala napravi 400 odlazaka. Možete mu kupiti brži viličar i bit će malo brži, ali pravo rješenje je da sve pokupi u jednom odlasku.
Poslovne aplikacije jako često rade upravo to. Najčešći uzroci sporosti nisu u snazi servera, nego u tome kako aplikacija radi:
- Stotine upita za jedan ekran. Aplikacija bazu pita za svaki redak posebno, umjesto jednom za sve.
- Baza bez pravih indeksa. Da bi našla jedan zapis, baza pročita cijelu tablicu. Dok je tablica mala, nitko to ne primijeti. Nakon pet godina podataka primijete svi.
- Izvještaji koji učitavaju sve. Aplikacija u memoriju povuče sve podatke, pa ih tek onda filtrira i zbraja, umjesto da to napravi baza.
- Pozivi vanjskim servisima jedan za drugim. Svaki poziv čeka prethodni, pa se sekunde zbrajaju.
- Ništa se ne pamti. Isti podaci koji se mijenjaju jednom dnevno računaju se ispočetka pri svakom otvaranju ekrana.
Jači server svaku od ovih stvari ubrza malo, a podataka svaki mjesec ima sve više. Zato se problem uvijek vrati.
Simptomi govore gdje tražiti
Ne morate biti programer da biste suzili krug. Ovo je ono što šef može primijetiti sam:
| Što primjećujete | Gdje je najčešće problem |
|---|---|
| Spori su samo neki ekrani ili izvještaji | U kodu ili upitima iza tih ekrana |
| Sve je sporije kako podataka ima više | U bazi: indeksi i način na koji se podaci dohvaćaju |
| Sporo je u određeno doba dana | Nešto drugo radi u isto vrijeme: noćni poslovi, backup, uvoz podataka |
| Sporo je od nove verzije | Promjena u toj verziji, i to se najbrže nađe |
| Sve je sporo, stalno, za sve | Tek tu je vrijeme da se gleda server i mreža |
Kako se sporost rješava: mjerenjem, a ne nagađanjem
Najskuplja greška je popravljati ono za što netko misli da je problem. Pravi redoslijed je uvijek isti:
- MjerenjeGdje točno odlazi vrijeme
- UzrokTri najveća krivca
- PopravakPrvo ono što najviše boli
- ProvjeraBrojke prije i poslije
- Mjerenje. Alati koji već postoje za .NET aplikacije i SQL Server točno pokažu koji ekran je spor, koliko upita šalje bazi i koliko svaki traje. Nakon toga nema nagađanja.
- Uzrok. Obično se pokaže da većinu problema rade dvije ili tri stvari. Njih se rješava prve.
- Popravak. Počinje se od onoga što korisnici najviše osjećaju: ekran koji svi otvaraju svaki dan važniji je od izvještaja koji se radi jednom mjesečno.
- Provjera. Isto mjerenje prije i poslije. Ne “čini se brže”, nego “ovaj ekran se otvarao 8 sekundi, a sad se otvara za jednu”.
Ovakvi popravci često su pitanje dana ili tjedana, a ne mjeseci, i ne traže prepisivanje aplikacije. Jednom napravljeni, ne naplaćuju se svaki mjesec kao veći server.
Kad ipak treba jači server
Ponekad treba. Ako mjerenje pokaže da je aplikacija napisana razumno, a server je stalno na granici jer korisnika i posla ima sve više, onda je jači server ispravna odluka. Razlika je u tome što tu odluku donosite na temelju brojki, a ne zato što je to najbrže reći.
Kako mi radimo
ProCoding je .NET studio iz Splita. Performanse su jedna od stvari koje radimo najčešće: na .NET aplikacijama, ASP.NET Coreu, Blazoru, Entity Frameworku, SQL Serveru i Azureu.
Počinjemo mjerenjem na vašoj aplikaciji i dobivate popis uzroka poredanih po tome koliko bole. Nakon toga ih popravljamo mi ili vaš tim, kako vam više odgovara. Prvi korak je besplatni razgovor od 30 minuta u kojem prođemo simptome i vidimo gdje bismo prvo mjerili.