Login Performance Test

스프링의 인터셉터, 스프링 시큐리티의 세션, 스프링 시큐리티의 jwt의 성능 차이를 수치로 확인하기 위해 시작한 프로젝트입니다.

💡 gatling 실험 결과는 📊 결과의 상세내용에서 아래와 같이 직접 확인하실 수 있습니다.

1️⃣ 테스트 시나리오

2️⃣ 아키텍처

3️⃣ 컨테이너 스펙

4️⃣ 기술 스택

5️⃣ 결과

6️⃣ 정리

7️⃣ 얻게 된 것

8️⃣ 관련 링크

---

📋 테스트 시나리오

 1️⃣ 로그인 시나리오
  유저는 로그인을 시도한다.

 2️⃣ 단순 요청 시나리오
  유저는 로그인을 시도한다.
  유저는 비즈니스 로직을 호출한다.(여기서는 단순 문자열만을 반환하는 로직을 비즈니스 로직이라 가정하였습니다.)

---

🏗 아키텍처

스프링의 인터셉터를 이용하여 구현하였을때의 아키텍처

스프링 시큐리티의 세션과 jwt를 이용하여 구현하였을때의 아키텍처

---

📦 컨테이너 스펙

• Ram 1GB
• Cpu 1Core

---

🛠️ 기술 스택

• Jdk17
• Spring Boot 3
• Redis
• MariaDB(테스트 환경)
• H2(개발 환경)
• Docker
• Prometheus
• Grafana
• Gatling

---

📊 결과

시나리오	구현 방법	CPU 사용량	JVM 사용량(1.5GB 기준)	DB 커넥션(최대 10)	톰캣 스레드	요청당 평균 응답속도	서버가 감당할 수 있는 최대 요청수	요청 처리 용량(Throughput)
로그인 시나리오	인터셉터	약 1%	346MB	100%	100%	5335ms	7129	1336.2
	시큐리티(세션)	약 1%	190MB	22.5%	93.8%	13132ms	194	14.7
	시큐리티(jwt)	약 0.93%	261.8MB	42%	64.1%	1781ms	3155	1771.4
단순 요청 시나리오	인터셉터	약 1%	365.6MB	약 98%	98%	5126ms	9629	1878.4
	시큐리티(세션)	약 1%	213MB	20%	98.25%	9418ms	216	22.9
	시큐리티(jwt)	약 1%	365MB	96%	100%	6535ms	9990	1528.6

상세내용

펼치기/접기

시나리오	구현 방법	첫번째 시도	두번째 시도	세번째 시도	네번째 시도	다섯번째 시도
로그인 시나리오	인터셉터	링크	링크	링크	링크	링크
	시큐리티(세션)	링크	링크	링크	링크	링크
	시큐리티(jwt)	링크	링크	링크	링크	링크
단순 요청 시나리오	인터셉터	링크	링크	링크	링크	링크
	시큐리티(세션)	링크	링크	링크	링크	링크
	시큐리티(jwt)	링크	링크	링크	링크	링크

---

✍️ 정리

• 구현 방식에 따라 응답속도, 감당할 수 있는 최대 요청수의 큰 차이가 존재하는 것을 확인할 수 있었습니다.
• jwt를 이용한 구현 방식이 session에 비해 최대 요청수와 평균 응답속도, 요청 처리 용량을 압도하는 것을 확인할 수 있었습니다.
• jwt를 사용하더라도 토큰 발급은 컨트롤러에서 하고 인증을 시큐리티의 사용자 정의 필터에서 한다면 , 인터셉터와 비슷한 수준의, 압도적인 성능을 뽑아낼 수 있음을 확인할 수 있었고 요청대비 리소스를 아낄 수 있음을 확인할 수 있었습니다.
• security의 session방식보다 security의 jwt방식이 로그인만 하는 상황에선 약 120배 , 로그인과 단순 요청을 하는 상황에선 약 60배 가량 더 높은 Throughput을 확인할 수 있었습니다.

---

🎁 얻게 된 것

• 로그인 방식별 장단점을 직접 데이터로 확인하며 비교할 수 있었습니다.
• 상황에 맞는 로그인 방식을 저만의 기준을 통해 선택할 수 있게 되었습니다.

---

♾️ 관련 링크

• https://github.com/sami355-24/login_performance_gatling
• https://github.com/sami355-24/login_performance_nGrinder
• https://goto-pangyo.tistory.com/279
• https://goto-pangyo.tistory.com/280