Testy wydajnościowe miały być formalnością. Ot, kilka endpointów, zewnętrzna aplikacja do dynamicznych cen i trochę danych z AWS Lambda. Po 17 sekundach odpowiedzi wszystko przestało być zabawne. Ten case pokaże, jak jeden zapomniany plugin potrafi zrujnować dzień, co z tego wynieśliśmy i jak testować, żeby nie było wstydu.

Prezentacja opowiada prawdziwą historię z projektu e-commerce, gdzie wdrażaliśmy dynamiczne ceny sterowane z zewnętrznego systemu. Zanim podpięliśmy właściwą integrację (której stworzenie wymagało również sporych kosztów), stworzyliśmy prosty symulator na AWS Lambda, który generował losowe ceny na potrzeby testów wydajnościowych.

Testy miały być tylko formalnością, a jednak już po kilku requestach response time poszybował do 17 sekund. Zaczęło się śledzenie logów, profilowanie i analizowanie, gdzie się wszystko sypie. Po nitce do kłębka doszliśmy do przyczyny: pojedynczy plugin zainstalowany kiedyś do developmentu, który niepotrzebnie manipulował hookami w każdej iteracji testu, co też było tylko charakterystyczne dla kont założonych na potrzeby testów. Po jego usunięciu – wszystko wróciło do normalnych 150ms.

W prezentacji opowiem:
• Jak wyglądał kontekst projektu i nasza architektura testów (WooCommerce + AWS Lambda + pricing microservice, testy k6),
• Jakie narzędzia i metody pomogły nam zdiagnozować problem (m.in. query monitor),
• Jakie błędy popełniliśmy w procesie testowania i jak je teraz adresujemy,
• Co ten przykład mówi o “niewinnych” pluginach, stagingu i higienie środowisk dev/test/prod.

Chcę, aby ta prezentacja była zarówno techniczną lekcją, jak i przestrogą – ale z przymrużeniem oka.