Wydajność aplikacji webowych: 3 martwe procesy, które rujnują UX

Wydajność aplikacji webowych: 3 martwe procesy, które rujnują UX

Pracując z wieloma firmami e-commerce i SaaS, regularnie widzę ten sam scenariusz: zespół narzeka na wolno działającą aplikację, ale po szybkim audycie okazuje się, że głównym winowajcą nie jest zbyt duży ruch czy słaby hosting, tylko procesy, które dawno powinny umrzeć. Martwe procesy – czyli zadania, które rozpoczęły się, ale nigdy nie zakończyły lub działają bez celu – to cichy zabójca wydajności i UX. W tym artykule pokażę, jak je rozpoznać, jakie generują koszty i co z nimi zrobić.

1. Niezakończone sesje użytkowników

Wyobraź sobie sytuację: klient wchodzi do sklepu, dodaje produkt do koszyka, ale zanim finalizuje zakup, rozprasza go telefon. Zostawia otwartą kartę przeglądarki i wraca po godzinie. W międzyczasie serwer trzyma otwartą sesję, alokuje pamięć RAM, utrzymuje stan koszyka. Jeśli Twój system nie ma mechanizmu wygaszania nieaktywnych sesji, z czasem te wiszące procesy zaczynają się kumulować.

Realny przykład z życia:
Klient z branży e-commerce odzieżowego narzekał, że jego aplikacja po 3 godzinach od uruchomienia działała jak w smole. Okazało się, że sesje użytkowników były utrzymywane przez 24 godziny bez limitu nieaktywności. Wystarczyło wdrożyć limity czasowe (np. 30 minut) oraz zautomatyzowane czyszczenie sesji, aby obciążenie serwera spadło o 40%, a czas ładowania strony skrócił się o połowę.

Biznesowy koszt:

• Zmarnowane zasoby serwera – płacisz za moc, która nie przynosi wartości.
• Gorsze doświadczenie dla aktywnych użytkowników – przy dużej liczbie wiszących sesji strona działa wolno dla wszystkich.
• Ryzyko błędów – przepełnienie pamięci może powodować losowe awarie.

Jak to naprawić?

• Wprowadź limit czasu trwania sesji (np. 30 minut od ostatniej aktywności).
• Regularnie czyść sesje za pomocą cron job lub dedykowanego skryptu.
• Rozważ użycie zewnętrznego magazynu sesji (np. Redis z TTL), który automatycznie usuwa przeterminowane dane.

2. Zombie processy w kolejce zadań

W nowoczesnych aplikacjach często korzystamy z kolejek zadań (RabbitMQ, AWS SQS, Redis Queue) do obsługi zadań asynchronicznych: wysyłka maili, generowanie raportów, przetwarzanie obrazów. Problem pojawia się, gdy zadanie trafia do kolejki, ale proces wykonawczy (worker) pada z powodu błędu lub restartu. Zadanie zostaje w kolejce, ale nikt go nie odbiera – to właśnie zombie process.

Realny przykład:
Firma SaaS oferująca narzędzie do fakturowania miała skargę od klienta: faktura nie została wysłana od 3 dni. Po debugowaniu okazało się, że worker odpowiedzialny za wysyłkę maili ulegał awarii co 50. zadaniu z powodu błędu w szablonie HTML. Każde kolejne zadanie trafiało na nowego workera, ale ten crashował się przy próbie wysyłki. W kolejce utknęło 10 000 zadań, a serwer bezskutecznie próbował je przetworzyć, marnując CPU i I/O.

Biznesowy koszt:

• Opóźnienia w dostarczaniu usług – klienci nie dostają maili, faktur, powiadomień.
• Zwiększone zużycie zasobów – ciągłe próby przetworzenia tego samego zadania.
• Spadek zaufania – jeśli klient nie otrzyma zamówienia na czas, pójdzie do konkurencji.

Jak to naprawić?

• Wdróż mechanizm dead letter queue (DLQ) – zadania, które nie mogą zostać przetworzone po X próbach, trafiają do osobnej kolejki do ręcznej analizy.
• Ustaw limit ponownych prób (retry policy) i timeout dla każdego zadania.
• Monitoruj liczby zadań w DLQ i konfiguruj alarmy.

3. Zablokowane zapytania do bazy danych

To najczęstszy i najbardziej zgubny typ martwego procesu. Zapytanie SQL, które długo się wykonuje, blokuje inne zapytania, powodując efekt kaskady. W środowisku produkcyjnym może to oznaczać, że kilka wolnych zapytań unieruchamia całą bazę, a z nią całą aplikację.

Realny przykład:
W sklepie internetowym z dużą bazą produktów, podczas codziennej aktualizacji cen, uruchamiano zapytanie aktualizujące milion rekordów. Zapytanie to blokowało tabelę produktów na 5 minut, co powodowało, że każdy inny odczyt (np. wyświetlenie kategorii) musiał czekać. Sklep stawał się niedostępny na 5 minut każdego dnia, co przy 1000 odwiedzających w tym czasie oznaczało utratę potencjalnych 200 zamówień dziennie.

Biznesowy koszt:

• Bezpośrednia utrata przychodów – jeśli sklep nie odpowiada, klient idzie dalej.
• Frustracja użytkowników – nawet jeśli strona ładuje się wolno przez 30 sekund, wielu klientów rezygnuje.
• Dodatkowe obciążenie zespołu IT – interwencje awaryjne odciągają od rozwoju.

Jak to naprawić?

• Wprowadź timeout na zapytania (np. 30 sekund) – zapytanie, które trwa dłużej, powinno być automatycznie zabijane.
• Używaj indeksów i optymalizuj zapytania (profiluj z EXPLAIN).
• W przypadku dużych aktualizacji, rozbijaj je na batch’e (np. 1000 rekordów na transakcję).
• Monitoruj zapytania z pomocą narzędzi takich jak pgstatactivity (PostgreSQL) lub sys.dmexecrequests (MSSQL).

Podsumowanie

Martwe procesy to nie tylko problem techniczny – to realny koszt biznesowy. Każdy z trzech opisanych przypadków kosztował firmy, z którymi pracowałem, dziesiątki tysięcy złotych w postaci utraconych przychodów i zmarnowanych zasobów. Dobrą wiadomością jest to, że diagnostyka i naprawa są stosunkowo proste, jeśli wiesz, czego szukać.

Kluczowe wnioski:

1. Regularnie audytuj swoje środowisko produkcyjne pod kątem wiszących sesji i zombie processów.
2. Wdróż monitoring i alarmy na długie zapytania oraz kolejki zadań.
3. Automatyzuj czyszczenie i retry’e, ale z głową – nie bez końca.

Jeśli masz wrażenie, że Twoja aplikacja działa wolniej niż powinna, a nie wiesz dlaczego – być może to właśnie martwe procesy wysysają energię z Twojego systemu. A skoro już jesteś świadomy problemu, możesz z nim walczyć. W JurskiTech specjalizujemy się w tego typu optymalizacjach – pomagamy firmom wycisnąć maksimum z posiadanej infrastruktury.