Stress Test (13) 썸네일형 리스트형 [Benchmark] Datasource 분리 이번 장에서는 시간이 많이 소비되는 요청(이하 비싼 요청)과 그렇지 않은 요청(이하 일반 요청)을 다른 Datasource에서 처리하도록 수정해보고 기존과 대비하여 어느정도 성능 향상이 있는지 알아본다. 지금까지의 부하 테스트와 벤치마크 결과를 자세하게 살펴보았다면 상당히 불합리한 결과가 보였을 것이다. 아래의 이미지와 같은 경우다. 실제로 요청을 처리하기위한 쿼리는 ms 단위에서 처리되었다. 하지만 다른 비싼 요청들 때문에 29초 동안 쿼리를 얻기위해 대기하였고 결론적으로 처리하는데 29초가 넘는 시간이 소비되었다. 즉, 몇몇 비싼 요청때문에 빠르게 처리되어야 할 요청까지 처리되지 못하였고 결과적으로 서비스가 전체적으로 느려진것이다. 몇몇 사용자의 비싼 요청때문에 누군가는 로그인하기 위해 30초를 기다.. [Benchmark] HikariCP 설정 [부하테스트] 결과 (1차) (링크)의 경우 엑셀 다운로드 시 발생하는 Memory 누수때문에 문제가 발생하였고 [부하테스트] 결과 (2차) (링크)의 경우 Tomcat Thread가 DB Connection을 얻지 못해서 문제가 발생하였다. 2차 부하 테스트에서 발생한 DB Connection 오류를 최소화하기 위하여 HikariCP 공식 Github (링크)를 참고하여 HikariCP 설정을 변경하였고 JPA OSIV (링크) 설정을 OFF로 변경하여 DB Connection을 기존보다 빠르게 반납할 수 있도록 수정하였다. (HikariCP 설정의 경우 MySQL DB에 최적화 된 방식이다. 만약 다른 DB를 사용하고 있다면 다른 최적화 설정을 참고해야한다.) 이번 장에서는 위에서 언급한 두 개의 옵.. [부하 테스트] 분석 (2차) 이번 장에서는 [부하 테스트] 결과 (2차) (링크)의 결과를 분석해보고 동접자 200명을 넘기지 못한 원인을 파악해본다. 결과에 따르면 100명까지는 서버가 정상적으로 버텨주었으므로 200명부터 500 Internal Server Error가 발생한 원인을 파악해본다. 분석 부하 테스트 1차와 달리 2차 테스트에서는 Docker Container가 Kill되지 않았다. 이러한 점을 보았을 때 리소스가 부족하지 않았을 것으로 예상된다. 실제로 Resource 사용량을 확인해본다. CPU 사용량의 경우 테스트 전 구간에서 10%를 넘기지 않았다. (최초 60%를 넘긴 부분은 컨테이너 초기화를 위해 서비스를 재기동한 부분이다.) Memory 사용량의 경우 테스트 전 구간에서 2GB를 넘기지 않았다. CPU와.. [부하 테스트] 결과 (2차) [부하 테스트] 결과 (1차) (링크)에서는 엑셀 다운로드시 memory 사용량이 급격하게 상승되고 이후 Garbage Collecting 되지 않아서 동접자 50명도 견디지 못하는 처참한 결과를 보았다. 이번 장에서는 문제가 발생한 코드를 수정한 코드를 가지고 다시 한번 부하 테스트를 진행하고 결과를 확인해본다. Dataset [부하 테스트] 결과 (1차) (링크)와 동일 테스트 순서 치명적인 문제가 해결되었으므로 부하의 강도를 상향 조절한다. 모든 테스트는 20분간 진행한다. (1차와 동일) 유저들은 60초 간격으로 무작위 요청한다. (1차와 동일) 동접자는 100명부터 시작하여 매번 테스트마다 100명씩 증가시켜 에러 응답률이 10%가 넘어가는 시점까지 진행한다. (1차의 2배) 테스트 결과 작성일.. [부하 테스트] 분석 (1차) 이번 장에서는 [부하 테스트] 결과 (1차) (링크)의 결과를 분석하여 문제가 발생한 시점을 파악해본다. 분석 가장 먼저 확인한 부분은 docker container의 상태를 저장한 파일이다. 기본적으로 컨테이너가 재실행 되었을 때 재실행 원인이 Status.ExitCode에 표시된다. 하지만 컨테이너가 세번이나 재실행되었음에도 ExitCode가 0으로 표시되어 해당 파일로는 원인을 파악이 불가능했다. (아마 컨테이너가 Kill되었을 경우 자동으로 Restart 되도록 설정해두었는데 Restart되면서 기록이 사라진게 아닐까 싶다.) "State": { "Status": "running", "Running": true, "Paused": false, "Restarting": false, "OOMKille.. [부하 테스트] 결과 (1차) 지금까지 부하 테스트를 진행하기 위해서 클라이언트 (Jmeter)를 설치하고 서버 설정을 진행하였다. 이번 장부터는 본격적으로 부하테스트를 진행하고 결과를 확인해보는 시간을 가져본다. 정확히는 필자의 환경에서 테스트를 진행하고 분석하는 과정을 살펴볼 것이다. Dataset 부하 테스트는 개발DB에 연결해서 진행한다. 부하 테스트를 위해 개발DB에 dummy 데이터를 Insert하였다. 상용DB와의 차이는 아래와 같다. 개발 상용 개발 - 상용 company 50 436 -386 company_manager 49 436 -387 company_member 92,985 8,022 84,963 comapny_settlement 2,224 0 2,224 allocation_mapping 455,396 22,39.. [부하 테스트] 서버 설정 이번 장에서는 부하테스트를 진행하는 동안 EC2 Instance의 리소스를 확인하기 위한 설정을 하는 방법에 대해서 알아본다. 필자의 경우 AWS를 사용해 서버를 구축하였기 때문에 EC2 Instance에 종속적인 설명이 될 수도 있다. 만약 필자가 설명한 방식으로 진행이 되지 않는다면 자신이 사용하는 Instance에 맞는 방식으로 바꿔서 진행해야한다. [부하 테스트] 개요(링크)에서 본 것과 같이 부하테스트의 대상이 되는 Instance에 설치된 nmon이 테스트 동안의 리소스 사용량을 기록한다. 기록된 파일을 nmonchart에 의해 보기 좋게 html 파일로 변경된다. 변경된 파일을 개발자의 브라우저로 옮겨서 확인하는 과정까지 이번장에서 알아보도록 한다. 관련 자료 nmon 공식 홈페이지(링크) .. [부하 테스트] Jmeter 상세 설정 이번 장에서는 Jmeter의 상세 설정부분들에 대해서 알아보도록 한다. Jmeter의 경우 상당히 많은 기능들을 가지고 있다. 이번 장에서는 필자가 사용한 기능들에 대해서만 다룰 예정이다. 만약 필자가 사용한 기능 이외에 다른 기능들이 필요하다면 아마 공식 홈페이지(링크)에서 잘 찾아보면 대부분의 기능들은 이미 존재할 것이다. {Test Group Name}: Test Group에서 사용할 Thread(일반적으로 유저)를 설정한다. Number of THreads (users): 테스트를 진행할 때 사용될 Threads(유저)의 수. Ramp-up Period (seconds): Number of Threads가 생성되는 시간. Loop Count: THread 단위로 요청하는 횟수. 아래의 이미지 기준.. 이전 1 2 다음
