Audyt wydajności aplikacji i bazy danych

Wolna aplikacja nie zawsze ma jedną prostą przyczynę

Ten sam objaw może mieć kilka źródeł. Ekran może długo czekać na odpowiedź bazy danych, zewnętrznego API albo kolejki. Problemem może być też zbyt duża liczba operacji, brak właściwego cache, sposób przetwarzania danych, konfiguracja środowiska lub część widoczna w przeglądarce.

Dlatego audytu nie zaczynamy od przypadkowego dodawania indeksów ani zmiany serwera. Najpierw ustalamy, który scenariusz jest ważny dla firmy, w jakich warunkach pojawia się problem i jak można go powtarzalnie zmierzyć. Dopiero potem sprawdzamy kolejne elementy systemu.

Kiedy taki audyt ma sens

Ważna czynność trwa coraz dłużej

Może to być otwieranie raportu, zapis zamówienia, wyszukiwanie, import danych, generowanie dokumentu albo operacja wykonywana przez pracownika wiele razy dziennie.

System zwalnia wraz ze wzrostem firmy

Więcej danych, użytkowników lub integracji ujawniło ograniczenie, którego wcześniej nie było widać. Chcesz wiedzieć, czy problem leży w zapytaniach, kodzie, architekturze czy środowisku.

Pojawiają się timeouty i niestabilne czasy odpowiedzi

Ta sama czynność raz działa szybko, a innym razem zatrzymuje proces. Dotyczy to zwłaszcza kolejek, cyklicznych zadań, integracji, importów i operacji wykonywanych równocześnie.

Masz kilka hipotez, ale brakuje dowodów

Jedna osoba proponuje mocniejszy serwer, druga przebudowę bazy, a trzecia zmianę frameworka. Audyt ma pomóc oddzielić przyczynę od objawu i ustawić prace we właściwej kolejności.

Najpierw ustalamy, co w tym systemie znaczy „wolno”

Nie istnieje jeden wynik, który opisze wydajność całej aplikacji. Inaczej mierzy się czas otwarcia publicznej strony, inaczej zapis dużego formularza, przeliczenie raportu, pracę kolejki czy import tysięcy rekordów.

Przed pomiarami uzgadniamy:

• konkretny ekran, czynność albo proces;
• środowisko i warunki, w których występuje problem;
• dane, liczbę operacji lub obciążenie potrzebne do odtworzenia sytuacji;
• dostępne pomiary, logi techniczne i ograniczenia dostępu;
• oczekiwany sposób sprawdzenia, czy przyszła poprawka pomogła.

Dzięki temu porównujemy takie same warunki i nie wyciągamy wniosków z pojedynczego, przypadkowego testu.

Przykład: wolny raport nie oznacza automatycznie braku indeksu

Załóżmy, że raport sprzedaży otwiera się kilkanaście sekund. Przyczyną może być jedno kosztowne zapytanie, ale również setki drobnych zapytań wykonywanych w pętli, oczekiwanie na zewnętrzną usługę, przetwarzanie zbyt dużej ilości danych w aplikacji albo generowanie odpowiedzi, której użytkownik nie potrzebuje w całości.

Dodanie indeksu bez sprawdzenia planu zapytania może niczego nie zmienić. Zwiększenie parametrów serwera może tylko odsunąć problem. Dlatego najpierw odtwarzamy sytuację, zbieramy pomiary i sprawdzamy, gdzie faktycznie upływa czas.

To przykład sposobu analizy, a nie opis konkretnego projektu ani obietnica, że każda aplikacja ma ten sam problem.

Co możemy sprawdzić

Dokładny zakres ustalamy przed rozpoczęciem. Nie każda aplikacja wymaga wszystkich poniższych obszarów.

Wykonujemy tylko pomiary bezpieczne dla uzgodnionego środowiska. Działania mogące zmienić dane, zwiększyć obciążenie albo wpłynąć na użytkowników wymagają osobnej decyzji i warunków testowych.

Jak przebiega audyt

1. Krótko kwalifikujemy problem

Rozmowa do 20 minut pomaga nam zrozumieć objaw, znaczenie biznesowe i potrzebne dostępy. Jest bezpłatna, ale nie zastępuje diagnozy, analizy kodu ani raportu.

2. Ustalamy zakres i bezpieczne warunki

Określamy badane scenariusze, środowisko, materiały, ograniczenia oraz format wyniku. Jeżeli potrzebny jest test obciążenia, ustalamy także jego skalę i sposób ochrony działającego systemu.

3. Odtwarzamy problem i zapisujemy stan początkowy

Zbieramy pomiary dla ustalonych czynności. Jeśli problemu nie można odtworzyć, opisujemy ograniczenie zamiast dopasowywać do niego wygodną hipotezę.

4. Izolujemy wąskie gardła

Sprawdzamy kolejne warstwy tylko w uzgodnionym zakresie. Porównujemy pomiary, plany wykonania i zachowanie aplikacji, aby wskazać przyczyny poparte dowodami.

5. Ustalamy priorytety i sposób weryfikacji

Oddzielamy szybkie poprawki od zmian wymagających większej przebudowy. Przy każdej ważnej rekomendacji opisujemy, jak po wdrożeniu sprawdzić jej efekt.

Co otrzymujesz

Zakres wyniku ustalamy w ofercie. Zwykle obejmuje on:

• opis badanego zakresu i warunków pomiaru;
• stan początkowy oparty na wykonanych pomiarach;
• potwierdzone wąskie gardła wraz z dowodami i priorytetem;
• zalecenia krótkoterminowe oraz zmiany wymagające dalszego rozwoju;
• sposób ponownej weryfikacji po wdrożeniu poprawek;
• proponowaną kolejność prac;
• osobną wycenę wdrożenia, jeżeli zakres da się rzetelnie określić.

Podsumowanie przekazujemy w formacie uzgodnionym przed rozpoczęciem. Możesz wykorzystać je podczas dalszych prac z Domin Software albo przekazać innemu wybranemu wykonawcy, z zachowaniem poufności i bez publicznego udostępniania materiałów.

Dlaczego sam wynik Lighthouse nie wystarczy

Lighthouse jest przydatny przy badaniu ładowania konkretnej strony w warunkach laboratoryjnych. Nie opisuje jednak samodzielnie działania bazy, kolejek, importów, panelu po zalogowaniu ani rzeczywistego zachowania wszystkich użytkowników.

Google rozdziela dane laboratoryjne od danych terenowych zbieranych od rzeczywistych użytkowników. Wyniki mogą się różnić ze względu na urządzenie, sieć, lokalizację i warunki testu. Dlatego, jeśli audyt obejmuje publiczną stronę, wynik Lighthouse traktujemy jako jedno ze źródeł, a nie jako całą diagnozę ani gwarancję określonej oceny.

W bazie danych liczy się plan wykonania, nie sama lista indeksów

Narzędzia baz danych pozwalają sprawdzić, jaki plan został wybrany dla zapytania i co wydarzyło się podczas jego wykonania. PostgreSQL i MySQL udostępniają do tego polecenia z rodziny EXPLAIN, a ich dokładne możliwości zależą od silnika i wersji.

Taki pomiar pomaga ocenić między innymi liczbę przetwarzanych wierszy, sposób łączenia danych i miejsca, w których zapytanie wykonuje więcej pracy, niż oczekiwano. Samo dodanie indeksu nie jest uniwersalnym rozwiązaniem: indeks musi odpowiadać rzeczywistemu zapytaniu i może wpływać także na zapis danych.

Metody diagnostyczne dobieramy do konkretnej bazy oraz środowiska. Nie uruchamiamy na produkcji kosztownych ani zmieniających dane operacji bez uzgodnienia bezpiecznych warunków.

Czego nie obejmuje podstawowy audyt

O ile oferta nie stanowi inaczej, podstawowy zakres nie obejmuje:

• wdrożenia wskazanych poprawek;
• stałego monitoringu i bieżącego utrzymania aplikacji;
• budowy dodatkowej infrastruktury do dużych testów obciążenia;
• pełnego audytu bezpieczeństwa albo kompletnego audytu aplikacji stworzonej z AI;
• gwarancji konkretnego wyniku Lighthouse, czasu odpowiedzi lub liczby obsługiwanych użytkowników;
• naprawy elementów, których nie można bezpiecznie zbadać w uzgodnionym środowisku.

Jeżeli analiza pokaże, że system wymaga szerszej przebudowy, dalszym krokiem może być modernizacja aplikacji. Gdy potrzebna jest stała opieka, monitoring i obsługa zmian, właściwą usługą jest utrzymanie aplikacji i sklepów. Wdrożenie pojedynczych zaleceń możemy wycenić jako osobny etap prac programistycznych.

Czas, wycena i rozliczenie

Audyt wyceniamy indywidualnie, ponieważ zakres zależy od liczby badanych procesów, technologii, dostępnych danych i warunków testu.

Roboczo zakładamy od 5 do 10 dni roboczych od otrzymania kompletu uzgodnionych dostępów i materiałów. Dokładny termin zapisujemy w ofercie.

Zwykle rozliczenie następuje po zakończeniu uzgodnionego etapu. Przy większym zakresie możemy ustalić zaliczkę. Jeśli po audycie zlecisz nam realizację dalszego projektu, koszt audytu wliczymy w całkowity koszt tych prac.

Najczęstsze pytania

Czy wystarczy przesłać wynik PageSpeed Insights albo Lighthouse?

Taki raport może pomóc rozpocząć rozmowę o publicznej stronie, ale nie zastąpi pomiarów konkretnego procesu. Nie pokaże samodzielnie przyczyny wolnego raportu, importu, zapisu danych, kolejki czy operacji po zalogowaniu.

Czy potrzebujecie dostępu do produkcji?

Nie zawsze. Zaczynamy od ustalenia, gdzie da się bezpiecznie odtworzyć problem. Preferujemy środowisko testowe albo kontrolowane pomiary. Dostęp do produkcji ustalamy tylko wtedy, gdy jest potrzebny i można ograniczyć jego zakres.

Czy audyt obejmuje wdrożenie poprawek?

Nie w podstawowym zakresie. Najpierw przekazujemy diagnozę i priorytety. Wdrożenie możemy wycenić osobno, a materiały możesz też przekazać innemu wykonawcy.

Czy dodanie indeksu rozwiąże problem z bazą?

Czasem właściwy indeks pomaga, ale nie każdemu zapytaniu i nie w każdej sytuacji. Najpierw sprawdzamy plan wykonania, ilość przetwarzanych danych i sposób użycia zapytania przez aplikację.

Jakie technologie możecie sprawdzić?

Najczęściej pracujemy z aplikacjami PHP, Laravel, sklepami i powiązanymi bazami danych. Inny stos technologiczny kwalifikujemy przed wyceną, aby nie obiecywać analizy obszaru, którego nie będziemy mogli rzetelnie sprawdzić.

Czy audyt jest możliwy bez wcześniejszego monitoringu?

Tak, jeżeli problem można odtworzyć i mamy wystarczające materiały do pomiaru. Jeżeli danych jest za mało, najpierw możemy zalecić ich bezpieczne zebranie. Takie ograniczenie zostanie jasno zapisane w wyniku.

Co przesłać na początek

W formularzu opisz:

• która czynność albo część systemu działa wolno;
• kiedy problem występuje i czy można go powtórzyć;
• jak wpływa na pracowników, klientów albo sprzedaż;
• przybliżoną liczbę użytkowników, rekordów lub operacji, jeśli ją znasz;
• używane technologie, jeżeli są znane;
• ostatnie większe zmiany w aplikacji lub środowisku;
• posiadane raporty i pomiary, bez wklejania poufnych danych.

Nie przesyłaj w formularzu haseł, kluczy API, kopii bazy ani danych klientów. Bezpieczny sposób przekazania potrzebnych materiałów ustalimy osobno.

Jeśli chcesz najpierw uporządkować dostępne informacje, przejdź checklistę materiałów do audytu wydajności. Narzędzie nie diagnozuje problemu i nie wymaga przesyłania danych poufnych.

CTA: Opisz problem z wydajnością

Źródła techniczne

• Google: Web Vitals - rozdzielenie danych terenowych i diagnostyki laboratoryjnej oraz ograniczenia pomiaru INP w typowym teście laboratoryjnym.
• Google: rozpoczynanie pomiarów Web Vitals - przyczyny różnic między danymi laboratoryjnymi a rzeczywistymi.
• PostgreSQL: Using EXPLAIN - plan wykonania i dane rzeczywiste dostępne podczas analizy zapytania.
• MySQL 8.0: Obtaining Execution Plan Information - plan wykonania oraz pomiary EXPLAIN ANALYZE.