Pracujac jako programista od dwoch lat, mialem okazje testowac swoje aplikacje na wielu maszynach. Zauwazylem jedno: to, co dziala plynnnie na moim laptopie, potrafi calkowicie zamarznac na starszym sprzecie klienta. Postanowilem wiec sprawdzic, jak naprawde wyglada wydajnosc kodu w roznych srodowiskach. Zamiast polegac na domyslach, wynajalem na kilka dni rozne konfiguracje sprzetowe przez the SWLAB online. Chcialem zobaczyc, czy moje optymalizacje maja sens w praktyce, czy tylko w teorii.
Zaczalem od testow na slabym laptopie z 4 GB RAM i procesorem Intel Core i3. Aplikacja webowa, ktora pisalem, miala renderowac wykresy w czasie rzeczywistym. Na moim glownym komputerze wszystko dzialalo idealnie. Na tym slabym sprzecie opoznienia siegaly prawie 3 sekund. Stanalem przed wyborem: albo przepisac caly modul, albo pogodzic sie z gorszym doswiadczeniem. Wybralem pierwsze.
Pierwszy test na maszynie wirtualnej z Windows 10
Kiedy uruchomilem maszyne przez zdalne laboratorium, pierwsze co zrobilem, to otworzenie menedzera zadan. Widzialem, jak procesor skacze do 100% przy kazdym odswiezeniu strony. To byla chwila prawdy. Zamiast wierzyc w benchmarki, ktore podaja idealne wyniki, dostalem rzeczywisty obraz. Zmodyfikowalem kod tak, aby czesc obliczen przeniesc na serwer, a nie obciazac przegladarki. Spadek zuzycia CPU o 45% mowil sam za siebie.
Druga proba na konfiguracji z Linuxem i 8 GB RAM
Przerzucilem sie na srodowisko linuksowe z wieksza pamiecia. Zdziwilo mnie, jak bardzo rozni sie zuzycie pamieci. Moja aplikacja, ktora na Windowsie jadla 1.2 GB, tutaj potrzebowala tylko 700 MB. To pokazalo, ze nie tylko kod ma znaczenie, ale tez system operacyjny. Przez nastepne dwa dni profilowalem kazdy endpoint REST API, szukajac wyciekow referencji. Znalazlem jeden blad w zarzadzaniu sesjami, ktory powodowal wolne narastanie pamieci o 50 MB na godzine.
Trzeci test na maszynie z dyskiem SSD i HDD
Wzialem pod uwage nie tylko procesor i RAM. Na tych samych parametrach, ale z roznymi dyskami, czas ladowania aplikacji roznil sie o 70%. Na HDD trwalo to 12 sekund, na SSD tylko 4. To mi przypomnialo, ze wydajnosc to nie tylko surowa moc obliczeniowa. Zoptymalizowalem cache dla plikow statycznych przez ustawienie dluzszych naglowkow HTTP. Efekt? Drugie ladowanie na HDD spadlo do 6 sekund.
Czwarty test z przegladarkami i ich wplywem
Sprawdzilem te sama aplikacje w Chrome, Firefox i Edge na tej samej maszynie wirtualnej. Rzucilo mi sie w oczy, ze Firefox renderowal skomplikowane interfejsy o 30% wolniej niz Chrome. To nie byla wina mojego kodu, ale silnika przegladarki. Zamiast walczyc z tym, dodalem fallback w postaci uproszczonego widoku dla starszych wersji. Testy pokazaly, ze uzytkownicy na Firefoxie mieli mniej bledow, choc aplikacja byla wolniejsza wizualnie.
Wydajnosc to nie tylko szybkosc, ale tez stabilnosc na roznych konfiguracjach. Lepiej miec aplikacje, ktora dziala poprawnie na 80% sprzetu, niz idealnie na 10%.
Piaty test z baza danych na zdalnym serwerze
Przenioslem baze danych na oddzielna maszyne przez zdalne srodowisko testowe. Zobaczylem, ze opoznienia sieciowe miedzy serwerem aplikacji a baza wynosily srednio 15 ms. To wplynelo na czasy odpowiedzi API. Zoptymalizowalem zapytania przez dodanie indeksow i zmniejszenie liczby joinow. Czas odpowiedzi spadl z 200 ms do 80 ms. To byl konkretny dowod, ze warto inwestowac w optymalizacje na poziomie bazy, a nie tylko frontendu.
Szosty test z obciazeniem symulacyjnym
Uruchomilem symulacje 50 jednoczesnych uzytkownikow na slabym sprzecie. Aplikacja zaczela zwalniac przy 35 uzytkownikach, a przy 50 padla calkowicie. Na mocniejszej maszynie wytrzymala 80 uzytkownikow bez problemu. To mi pokazalo, ze skalowalnosc zalezy od sprzetu bardziej niz od kodu. Zaimplementowalem kolejkowanie zadan przez Redis, co pozwolilo na obsluge 60 uzytkownikow nawet na slabym sprzecie. Roznica byla widoczna od razu w logach.
Siodmy test z monitorowaniem w czasie rzeczywistym
Ostatniego dnia skonfigurowalem proste monitorowanie przez narzedzia systemowe. Zbieralem dane o zuzyciu CPU, RAM i dysku co minute przez 8 godzin. Okazalo sie, ze szczyt obciazenia wystepowal rano i po poludniu, a nie wieczorem, jak zakladalem. To zmienilo moj harmonogram aktualizacji serwera. Przenioslem je na godziny nocne, aby nie przeszkadzac uzytkownikom w godzinach szczytu. Zdalne srodowisko testowe pozwolilo mi na taka analize bez ryzyka dla produkcji.
Comments are closed, but trackbacks and pingbacks are open.