Stress Testy 12.2023

Inicjalizacja rekurencji z 3DS

W czasie testów wyszło:

• potrzeba dorzucenia cache’a na klucze RSA generowane pod Widget - bez tego w czasie testów z C+ czasy odpowiedzi z HSM leciały w kosmos

  

  HSM without RSA Key cache

  

  HSM with RSA Key cache

• ustawienie timeoutSeconds na livenessProbe na hsmmulti na 5 sec, defaultowy czas 1 sec powodował, że momentami wypadały hc i dorzucał restartowanie poda

• zauważone duże użycie RAMu przez cardsapi-jboss (wciąga całe 4GB jakie ma w limitach) - możliwe, że trzeba dorzucić więcej

• frontapi i pozostałem elementy bez zadyszki

Płatność w tle z mockiem 106

• odpalony locust na 100 userów, wyciągał 100trx/s, po stronie systemów generalnie dość spokojnie, frontapi nawet się nie wyskalowało powyżej 3 replik

• Mock Płatności - lagował na kafce pod zbieranie i zatwierdzanie płatności - do popatrzenia cyz da się z niego jeszcze więcej wycisnąć bez jakichś czarów

• TIR - łapał lekko laga na AMQ na PayStatus na 2 replikach, HPA nie wyskalowało bo CPU zimne miał

  • do sprawdzenia czy 3 lub 4 repliki tira ogarną na bieżąco

• rozładowanie górki zajęło 10min po zatrzymaniu startowania transakcji

  

  

  Trx/s

  

  locust report

Porównanie HSM-ów

data

Testy były przeprowadzone na środowisku STG pod obciążeniem (locust 100 users) w 4 wariantach:

• HSM1 (stary) z uwzględnieniem cache’owania na metodzie generatePEMCertificate

• HSM1 (stary) bez cache’a na metodzie generatePEMCertificate

• HSM2 (nowy) z uwzględnieniem cache’owania na metodzie generatePEMCertificate

• HSM2 (nowy) bez cache’a na metodzie generatePEMCertificate

Powyższe testy pokazały, że czasy odpowiedzi są zdecydowanie dłuższe na hsm1 - 4 pierwsze części wykresów to HSM1, a 4 ostatnie części - to HSM2.

Metoda HealthCheck

Metoda AESResource.decrypt

Metoda RSAResource.getKeyForEncryption

Wnioski

• stress testy przeprowadzane cyklicznie w powtarzalny sposób poprawią nasz sposób tworzenia oprogramowania, bo “wbudują” świadomość w developerów

• frontapi zachowuje się zdecydowanie stabilniej niż w czasie testów sierpniowo/wrześniowych

• największy zysk wynika najprawdopodobniej z oddzielenia Hazelcasta żeby stał jako osobny deployment

• “stary” hsm dużo szybciej się dusi niż “nowy” co limituje maksymalne osiągi na defaultowej konfiguracji środowiska STG (korzysta tylko ze starego)