Jak realnie sprawdzić wydajność aplikacji przed skalowaniem? 3 testy, które każdy CTO powinien znać

Wstęp

Scaling-up – magiczne słowo, które pojawia się w każdym pitch decku i na spotkaniach zarządu. Ale prawda jest taka, że większość firm rzuca się na skalowanie jak na ratunek, zanim w ogóle sprawdzi, czy aplikacja na to zasługuje. Widziałem to wielokrotnie: startup dostaje pierwszy większy ruch, deweloperzy panikują, zarząd każe dokupić serwery, a po tygodniu okazuje się, że aplikacja działa równie wolno, tylko rachunki są wyższe. Brzmi znajomo?

Skalowanie w górę (ang. vertical scaling) lub na zewnątrz (ang. horizontal scaling) bez solidnych danych to jak kupowanie większego samochodu, bo źle wyregulowałeś gaźnik. W dzisiejszych czasach, gdy każda milisekunda opóźnienia kosztuje konwersję, a budżety MŚP są napięte, nie możesz pozwolić sobie na zgadywankę. Dlatego zanim wydasz pierwsze pieniądze na nową infrastrukturę, przeprowadź te trzy testy. Pokażą Ci, gdzie leży prawdziwy problem: w kodzie, w architekturze, czy w konfiguracji.

1. Test obciążeniowy z profilem użytkownika – symuluj realny scenariusz

Pierwszym krokiem jest test obciążeniowy, ale nie byle jaki – chodzi o test, który odzwierciedla rzeczywiste ścieżki użytkowników w Twojej aplikacji. Zbyt często widzę, jak firmy używają narzędzi takich jak Apache JMeter czy Locust do symulacji ruchu, ale robią to źle. Wysyłają setki zapytań do jednego endpointu, który rzadko jest faktycznie obciążany, albo ignorują myślenie użytkownika (czas między akcjami). Rezultat? Dane mówią, że aplikacja wytrzymuje 1000 RPS, a w praktyce na 200 użytkownikach pada.

Jak to zrobić poprawnie?

Zacznij od analizy dzienników serwera lub Google Analytics. Dowiedz się, które ścieżki są najczęściej używane – logowanie, przeglądanie produktów, dodawanie do koszyka, finalizacja zamówienia. Stwórz scenariusz testowy, który odtworzy te kroki z opóźnieniami między akcjami (np. 3-5 sekund). Użyj narzędzia, które pozwoli na stopniowe zwiększanie liczby wirtualnych użytkowników, aż do momentu, gdy czas odpowiedzi przekroczy akceptowalny próg (np. 2 sekundy na stronę).

Co to daje?

Taki test od razu pokaże, gdzie aplikacja zaczyna zwalniać. Może to być konkretny zapytanie do bazy danych, słabo zoptymalizowany kod backendu, albo zbyt mała pula połączeń. Zamiast zgadywać, otrzymasz twarde dane, które możesz przedstawić deweloperom. Pamiętaj, że skalowanie nie naprawi złych zapytań SQL – wręcz przeciwnie, dodanie większej mocy może zamaskować problem, ale on wróci w momencie, gdy ruch skoczy.

Przykład z życia:
Pracowałem z klientem, który narzekał, że jego aplikacja e-commerce zwalnia przy 500 użytkownikach. Zrobiliśmy test obciążeniowy i okazało się, że jeden endpoint – listowanie produktów – wykonywał zapytanie bez indeksu, które przy 200 użytkownikach trwało 8 sekund. Dodanie indeksu skróciło czas do 50 ms, a aplikacja obsłużyła 5000 użytkowników bez zmian w infrastrukturze. Koszt? Trzy godziny pracy developera. Zamiast dokładać serwery za 2000 zł miesięcznie.

2. Test wąskiego gardła (bottleneck identification) – użyj narzędzi APM

Drugi test to identyfikacja wąskich gardeł na każdym poziomie: CPU, pamięć, I/O dysku, sieć, pula połączeń do bazy danych, kolejka zadań asynchronicznych. Sam test obciążeniowy powie Ci, że aplikacja zwalnia, ale nie powie dokładnie gdzie. Potrzebujesz narzędzi Application Performance Monitoring (APM) takich jak New Relic, Datadog, czy open-source’owy Prometheus z Grafana.

Jak to zrobić poprawnie?

Podczas testu obciążeniowego uruchom monitoring na wszystkich serwerach i w samej aplikacji. Patrz na metryki:

• Zużycie CPU – czy procesor jest bliski 100%? Jeśli tak, to masz problem z obliczeniami (np. słaba optymalizacja algorytmów, pętle w pętlach).
• Zużycie pamięci – czy aplikacja alokuje coraz więcej pamięci i nie zwalnia? To może wskazywać na wycieki pamięci.
• I/O dysku – czy dyski są przeciążone? Wskazówka: w dzisiejszych czasach to zwykle sygnał, że dane nie są cache’owane prawidłowo.
• Zapytania do bazy danych – które zapytania są najwolniejsze? Narzędzia APM często pokazują ślad zapytania i czas wykonania.
• Czas odpowiedzi na poszczególnych endpointach.

Co to daje?

Zamiast kupować więcej serwerów, możesz często rozwiązać problem przez:

• Dodanie indeksów do bazy
• Zastosowanie cache’u (np. Redis) dla często używanych danych
• Poprawienie algorytmów
• Zwiększenie puli połączeń (ale z umiarem, bo to może też zaszkodzić)

Przykład z życia:
Klient z branży fintech: aplikacja do przetwarzania płatności zwalniała przy 300 transakcjach na minutę. Monitoring pokazał, że CPU jest na niskim poziomie, ale pamięć stale rośnie. Debugowanie wykazało wyciek pamięci w jednym serwisie odpowiedzialnym za generowanie PDF-ów – nie zwalniał on zasobów po zakończeniu zadania. Naprawa wycieku zajęła dwa dni, a aplikacja zaczęła obsługiwać 1500 transakcji bez zmiany sprzętu.

3. Test skalowalności horyzontalnej – dodaj węzły i mierz efektywność

Trzeci test to sprawdzenie, czy Twoja aplikacja w ogóle nadaje się do skalowania horyzontalnego – czyli dodawania kolejnych instancji. To test, który większość firm pomija w pośpiechu, a potem dziwią się, że dodanie drugiego serwera nie daje podwojenia wydajności. Dlaczego? Bo często aplikacja ma stan (session state, stan w pamięci) lub używa monolitycznej bazy danych, która staje się wąskim gardłem.

Jak to zrobić poprawnie?

Postaw dwie instancje swojej aplikacji (np. na Dockerze lub w chmurze) i skonfiguruj load balancer. Następnie uruchom test obciążeniowy na jednej instancji, zmierz maksymalny przepływ (np. 500 RPS). Potem uruchom ten sam test na dwóch instancjach i zobacz, czy przepływ wynosi 1000 RPS. Jeśli nie, to znaczy, że występuje overhead na komunikację między instancjami, problem ze współdzieleniem stanu lub baza danych jest bottleneckiem.

Co to daje?

Test ten ujawni problemy architektoniczne. Na przykład:

• Aplikacja przechowuje sesje lokalnie w pamięci – load balancer musi kierować tego samego użytkownika do tej samej instancji (sticky sessions), co uniemożliwia prawdziwe skalowanie.
• Baza danych nie radzi sobie z dużą liczbą połączeń – potrzebujesz replikacji lub shardingu.
• Komunikacja między instancjami (np. przez gniazda) generuje opóźnienia.

Przykład z życia:
Startup SaaS: aplikacja do zarządzania projektami. Próbowali skalować horyzontalnie, ale po dodaniu drugiej instancji wydajność wzrosła tylko o 30%. Okazało się, że wszystkie stany sesji były przechowywane w plikach na lokalnym dysku każdej instancji – load balancer był zmuszony do kierowania użytkowników do tej samej instancji, co powodowało przeciążenie jednego węzła. Rozwiązanie: przeniesienie sesji do Redis – po tym rozwiązaniu dodanie drugiej instancji dało prawie 100% wzrost wydajności.

Podsumowanie

Zanim zdecydujesz się na skalowanie – w pionie czy poziomie – wykonaj te trzy testy. Kosztują one kilka godzin pracy, a mogą zaoszczędzić tysiące złotych miesięcznie.

1. Test obciążeniowy z profilem użytkownika – symuluj rzeczywiste ścieżki, nie tylko puste zapytania.
2. Test wąskiego gardła (APM) – znajdź dokładne miejsce wolnego działania.
3. Test skalowalności horyzontalnej – sprawdź, czy architektura w ogóle pozwala na dodanie węzłów.

W dzisiejszych realiach, gdzie każda sekunda opóźnienia to utrata klienta, a budżety MŚP są napięte, nie stać Cię na zgadywanie. Skalowanie powinno być odpowiedzią na rzeczywistą potrzebę, a nie panicznym działaniem. Pamiętaj, że często lepszy kod i odpowiednie indeksy w bazie danych są tańsze niż dodatkowe serwery.

Jeśli potrzebujesz pomocy w przeprowadzeniu takich testów lub audycie wydajności Twojej aplikacji – JurskiTech.pl od lat pomaga firmom mądrze skalować. Nie hejtujemy budżetów na chmurę – optymalizujemy rzeczywiste źródło problemu.