<div id="readability-page-1" class="page"><div><p>이전 포스팅: </p>
<ul>
<li><a href="https://velog.io/@max9106/nGrinderPinpoint-test1">nGrinder와 Pinpoint를 이용한 성능 / 부하 테스트1 - 테스트 계획</a></li>
<li><a href="https://velog.io/@max9106/nGrinderPinpoint-test2">nGrinder와 Pinpoint를 이용한 성능 / 부하 테스트2 - 시나리오 작성</a></li>
</ul>
<hr>
<h3 id="테스트-범위">테스트 범위</h3>
<p><img src="https://media.vlpt.us/images/max9106/post/d1aaedc9-b420-4179-b7d8-09423a21d4ce/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-07%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2011.12.31.png"></p>
<h3 id="데이터-개수">데이터 개수</h3>
<ul>
<li>각 테이블 당 20만개 </li>
</ul>
<h2 id="-사전-지식">🔎 사전 지식</h2>
<p>nGrinder를 통해 테스트를 진행하면 아래와 같은 형식의 그래프를 결과값으로 볼 수 있습니다.</p>
<p><img src="https://media.vlpt.us/images/max9106/post/b7d9e181-8d47-4600-8472-86836d7a1c4d/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%208.09.27.png"></p>
<p>nGrinder의 TPS는 <code>Test Per Seconds</code>의 약자로 초당 몇 번의 테스트가 일어났는지를 뜻합니다.</p>
<p>위의 그래프 중 <code>TPS 그래프</code>는 <strong>초당 몇번의 테스트가 일어났는지</strong>를 나타내며, <code>평균 테스트 시간 그래프</code>는 <strong>한 번의 요청부터 응답까지 몇 초가 걸렸는지</strong>를 나타냅니다.</p>
<p>이 두 가지 요소를 중점적으로 살펴보면 됩니다.</p>
<p>하지만 이 그래프에는 문제가 하나 있습니다. 위의 그래프들은 시나리오에 포함된 모든 요청에 대한 <strong>평균값</strong>을 나타냅니다. 따라서 제 시나리오를 예시로 들면 시나리오 안에 총 7개의 요청이 있기 때문에 7개 요청의 평균값을 그래프로 나타낸 것입니다. 따라서 <strong>특정 요청에 대한 결과</strong>를 보기는 힘듭니다. </p>
<p>이는 로그 파일이나 CSV 파일을 통해 파악할 수 있습니다.</p>
<h3 id="로그-파일--csv-파일-활용하기">로그 파일 &amp; CSV 파일 활용하기</h3>
<p>로그 파일은 테스트가 끝난 후 확인할 수 있습니다.<br>
<img src="https://media.vlpt.us/images/max9106/post/5777bff6-be75-4135-80b4-37643ead9013/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%208.58.00.png"></p>
<p><img src="https://media.vlpt.us/images/max9106/post/834b398b-9ccd-4081-b843-1aa3e9bf9b4d/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%208.56.09.png"></p>
<p>좀 더 자세한 정보는 CSV 파일로 확인할 수 있습니다. CSV파일은 <code>상세보고서</code>를 클릭 하신 후, 우측 상단의 <code>CSV 다운로드</code>를 누르시면 다운받을 수 있습니다.</p>
<p><img src="https://media.vlpt.us/images/max9106/post/ceb26c81-5452-496c-aea6-f857a5e4c67d/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%208.28.18.png"></p>
<p>CSV 파일은 각 가로로 각 요청당 결과값을 볼 수 있습니다. Description부터 다음 요청의 Description 전까지가 해당 요청의 결과값입니다.  <code>TPS-${요청번호}</code>, <code>Mean_Test_Time_(ms)-${요청번호}</code>와 같은 형식으로 해당 요청의 결과를 볼 수 있습니다. CSV의 세로는 시간을 나타냅니다.</p>
<h3 id="pinpoint-활용하기">Pinpoint 활용하기</h3>
<p>각 요청에 대한 처리 시간은 <code>Pinpoint</code>를 활용하여 자세히 확인할 수 있습니다.</p>
<p>부하 테스트를 진행한 시간대를 설정해주면 아래와 같이 시간대에 따른 요청을 초록색 점으로 나타냅니다. 하나의 점이 하나의 요청입니다. </p>
<p><img src="https://media.vlpt.us/images/max9106/post/5ff05380-0aa5-4856-8395-cdb1ca12cc4f/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%209.03.16.png"></p>
<p>초록색 점들을 드래그 해보면 각 요청에 대한 세부 정보(각 메서드 당 실행 시간 등)를 확인할 수 있습니다.<br>
<img src="https://media.vlpt.us/images/max9106/post/9df5b869-be16-44e6-8fa1-46e6b8bfe487/pinpoint.gif"></p>
<h2 id="-smoke-test">📈 Smoke Test</h2>
<p>최소한의 부하를 견딜 수 있는지 smoke 테스트를 먼저 진행해보겠습니다. 최소한의 부하이므로 테스트 시간은 10분 정도만 진행하겠습니다. 스크립트는 이전 포스팅에서 작성한 스크립트를 이용합니다.</p>
<ul>
<li>VUser: 2</li>
<li>테스트 시간: 10분</li>
</ul>
<p><img src="https://media.vlpt.us/images/max9106/post/4ac28f64-511a-4ae9-bd7c-b935ed354f30/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%207.57.33.png"></p>
<p>목표는 아래와 같습니다.</p>
<ul>
<li>TPS(Throughput): 11.3 ~ 34 이상</li>
<li>MTT(Latency): 50 ~ 100ms 이하</li>
</ul>
<h3 id="결과">결과</h3>
<p><img src="https://media.vlpt.us/images/max9106/post/b7d9e181-8d47-4600-8472-86836d7a1c4d/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%208.09.27.png"></p>
<p><img src="https://media.vlpt.us/images/max9106/post/57cec214-812f-4954-bd09-6fab6748656a/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%209.09.45.png"></p>
<p>TPS는 데이터의 개수가 많아서인지 VUser가 2명 밖에 안되는데 생각보다 낮게 나왔습니다. WAS에서 병목이 일어난건지, DB에서 병목이 일어난건지 잘 모르겠지만 데이터의 수가 많기 때문에 DB쪽이 아닐까 추측이 들어 DB Replication을 적용해보고 다시 측정해보겠습니다.</p>
<p>다른 요청들은 괜찮은데, 3번째 요청인 <code>리뷰어 목록을 조회하는 요청</code>의 시간이 많이 걸리는 것을 볼 수 있습니다.</p>
<p>Pinpoint도 한 번 살펴보겠습니다.</p>
<p><img src="https://media.vlpt.us/images/max9106/post/5ff05380-0aa5-4856-8395-cdb1ca12cc4f/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%209.03.16.png"></p>
<p>대부분의 요청은 100ms 아래로 보여지는데, 특정 요청들이 1000ms 정도 걸리는 것을 볼 수 있습니다. 위의 로그 파일에서 살펴본 <code>리뷰어 목록을 조회하는 요청</code>이라고 추측됩니다. 드래그를 해서 한 번 살펴보겠습니다.</p>
<p><img src="https://media.vlpt.us/images/max9106/post/80864a48-6ff3-46cb-927d-88b76114dff1/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%209.14.48.png"></p>
<p><code>TeacherFilterRepository</code> 클래스의 <code>findAll()</code>메서드에서 시간이 오래걸리는 것을 파악할 수 있습니다. 이 조회 쿼리를 개선해야 해당 요청의 성능이 좋아질 것이라는 것을 알 수 있습니다.</p>
<h3 id="todo">TODO</h3>
<ul>
<li>DB replication 적용</li>
<li>findAll 조회 쿼리 개선 </li>
</ul>
<h2 id="-load-test">📈 Load Test</h2>
<p>평균 트래픽일 경우와 최대 트래픽일 경우를 나눠서 테스트해보겠습니다. 테스트 시간은 30분으로 진행합니다.</p>
<p>평균 트래픽</p>
<ul>
<li>VUser: 7</li>
<li>테스트 시간: 30분<br>
<img src="https://media.vlpt.us/images/max9106/post/24663863-8e88-444e-b623-8dffa6643f7d/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-11%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2012.53.37.png"></li>
</ul>
<p>최대 트래픽</p>
<ul>
<li>VUser: 22</li>
<li>테스트 시간: 30분<br>
<img src="https://media.vlpt.us/images/max9106/post/bcb22383-d7cd-4f9a-abb6-71610e691d53/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-11%20%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB%2012.54.04.png"></li>
</ul>
<p>두 테스트 모두 목표는 아래와 같습니다.</p>
<ul>
<li>TPS: 11.3 ~ 34 이상</li>
<li>MTT: 50 ~ 100ms 이하</li>
<li>성능 유지 기간: 30분</li>
</ul>
<h3 id="평균-트래픽-결과">평균 트래픽 결과</h3>
<p><img src="https://media.vlpt.us/images/max9106/post/e5b072b9-eccc-4088-9c96-2349af7e75c6/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%209.20.58.png"></p>
<p><img src="https://media.vlpt.us/images/max9106/post/718c9b64-da86-49d4-ab68-12e20fed2fff/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%209.21.17.png"></p>
<p>이미 smoke 테스트에서도 문제가 있었던 <code>리뷰어 목록을 조회하는 요청</code>이 거의 2배가 걸리게 되었고, <code>로그인 요청</code>도 꽤 시간이 늘어났습니다.</p>
<p>Pinpoint로도 살펴보겠습니다.<br>
<img src="https://media.vlpt.us/images/max9106/post/925f43f1-2d96-4095-8b6e-e5c2008f419c/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%209.34.58.png"><br>
<img src="https://media.vlpt.us/images/max9106/post/7f78cce7-4f42-4d9d-ac83-4d25d8fa8e9b/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%209.36.50.png"></p>
<p><code>TeacherFilterRepository</code> 클래스의 <code>findAll()</code>메서드의 문제가 심각하다는 걸 알 수 있습니다.</p>
<p><img src="https://media.vlpt.us/images/max9106/post/4c14fe98-e440-4cac-aa0d-80c2bf2004a5/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%209.40.45.png"></p>
<p>로그인 과정에서 일어나는 조회쿼리 또한 개선이 필요해보입니다.</p>
<h3 id="최대-트래픽-결과">최대 트래픽 결과</h3>
<p><img src="https://media.vlpt.us/images/max9106/post/65470daf-2c0b-4c5d-b248-661be92d64a3/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%209.43.13.png"></p>
<p><img src="https://media.vlpt.us/images/max9106/post/b88d8b42-e980-4fd5-bf68-28ce3578e6b2/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%209.43.30.png"></p>
<p>운영 중 최대 트래픽(가정)일 경우 전반적으로 모든 요청의 시간이 목표를 오버해버렸습니다.. 🤦🏻‍♂️</p>
<p>Pinpoint도 살펴보겠습니다.<br>
<img src="https://media.vlpt.us/images/max9106/post/ebc39b4d-23f9-45e8-989c-2ae4f48b9f06/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%209.46.21.png"></p>
<p><img src="https://media.vlpt.us/images/max9106/post/36094577-8817-4208-9172-2aaa76012bdc/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA%202021-10-10%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%209.49.07.png"></p>
<p>당연히 이미 문제가 되었던 쿼리는 더 성능이 안좋아졌고, 새로운 문제도 찾을 수 있었습니다. connection 과정에서 많은 비용이 소모되는 걸 볼 수 있었습니다. 다른 요청들도 모두 시간이 늘어났으므로 모두 확인해보니 findAll과 login을 제외한 요청은 전부 connection에서 비용이 확 증가한 것이었습니다. connection pool도 조정해야겠습니다.</p>
<h3 id="todo-1">TODO</h3>
<ul>
<li>DB replication 적용</li>
<li>findAll 조회 쿼리 개선 </li>
<li>login 내부 조회 쿼리 개선</li>
<li>connection pool 조정</li>
</ul>
<h2 id="-개선하기">🛠 개선하기</h2>
<p>smoke 테스트와 load 테스트를 통해 개선해 나갈 방향을 잡아보았습니다.</p>
<ul>
<li>DB replication 적용</li>
<li>findAll 조회 쿼리 개선 </li>
<li>login 내부 조회 쿼리 개선</li>
<li>connection pool 조정</li>
</ul>
<p>다음 포스팅에서는 개선을 통해 smoke, load 테스트 결과가 어떻게 바뀌는지 알아보겠습니다. 개선을 통해 어느정도 만족할 만한 결과가 나온다면 stress 테스트를 통해 한계점을 찾아보겠습니다.</p></div></div>

air.log

이전 포스팅: 
nGrinder와 Pinpoint를 이용한 성능 / 부하 테스트1 - 테스트 계획
nGrinder와 Pinpoint를 이용한 성능 / 부하 테스트2 - 시나리오 작성
테스트 범위
데이터 개수
각 테이블 당 20만개 
🔎 사전 지식
nGrinder를 통해 테스트를 진행하면 아래와 같은 형식의 그래프를 결과값으로 볼 수 있습니다.
nGrinder의 TPS는 Test Per Seconds의 약자로 초당 몇 번의 테스트가 일어났는지를 뜻합니다.
위의 그래프 중 TPS 그래프는 초당 몇번의 테스트가 일어났는지를 나타내며, 평균 테스트 시간 그래프는 한 번의 요청부터 응답까지 몇 초가 걸렸는지를 나타냅니다.
이 두 가지 요소를 중점적으로 살펴보면 됩니다.
하지만 이 그래프에는 문제가 하나 있습니다. 위의 그래프들은 시나리오에 포함된 모든 요청에 대한 평균값을 나타냅니다. 따라서 제 시나리오를 예시로 들면 시나리오 안에 총 7개의 요청이 있기 때문에 7개 요청의 평균값을 그래프로 나타낸 것입니다. 따라서 특정 요청에 대한 결과를 보기는 힘듭니다. 
이는 로그 파일이나 CSV 파일을 통해 파악할 수 있습니다.
로그 파일 & CSV 파일 활용하기
로그 파일은 테스트가 끝난 후 확인할 수 있습니다.
좀 더 자세한 정보는 CSV 파일로 확인할 수 있습니다. CSV파일은 상세보고서를 클릭 하신 후, 우측 상단의 CSV 다운로드를 누르시면 다운받을 수 있습니다.
CSV 파일은 각 가로로 각 요청당 결과값을 볼 수 있습니다. Description부터 다음 요청의 Description 전까지가 해당 요청의 결과값입니다.  TPS-${요청번호}, Mean_Test_Time_(ms)-${요청번호}와 같은 형식으로 해당 요청의 결과를 볼 수 있습니다. CSV의 세로는 시간을 나타냅니다.
Pinpoint 활용하기
각 요청에 대한 처리 시간은 Pinpoint를 활용하여 자세히 확인할 수 있습니다.
부하 테스트를 진행한 시간대를 설정해주면 아래와 같이 시간대에 따른 요청을 초록색 점으로 나타냅니다. 하나의 점이 하나의 요청입니다. 
초록색 점들을 드래그 해보면 각 요청에 대한 세부 정보(각 메서드 당 실행 시간 등)를 확인할 수 있습니다.
📈 Smoke Test
최소한의 부하를 견딜 수 있는지 smoke 테스트를 먼저 진행해보겠습니다. 최소한의 부하이므로 테스트 시간은 10분 정도만 진행하겠습니다. 스크립트는 이전 포스팅에서 작성한 스크립트를 이용합니다.
VUser: 2
테스트 시간: 10분
목표는 아래와 같습니다.
TPS(Throughput): 11.3 ~ 34 이상
MTT(Latency): 50 ~ 100ms 이하
결과
TPS는 데이터의 개수가 많아서인지 VUser가 2명 밖에 안되는데 생각보다 낮게 나왔습니다. WAS에서 병목이 일어난건지, DB에서 병목이 일어난건지 잘 모르겠지만 데이터의 수가 많기 때문에 DB쪽이 아닐까 추측이 들어 DB Replication을 적용해보고 다시 측정해보겠습니다.
다른 요청들은 괜찮은데, 3번째 요청인 리뷰어 목록을 조회하는 요청의 시간이 많이 걸리는 것을 볼 수 있습니다.
Pinpoint도 한 번 살펴보겠습니다.
대부분의 요청은 100ms 아래로 보여지는데, 특정 요청들이 1000ms 정도 걸리는 것을 볼 수 있습니다. 위의 로그 파일에서 살펴본 리뷰어 목록을 조회하는 요청이라고 추측됩니다. 드래그를 해서 한 번 살펴보겠습니다.
TeacherFilterRepository 클래스의 findAll()메서드에서 시간이 오래걸리는 것을 파악할 수 있습니다. 이 조회 쿼리를 개선해야 해당 요청의 성능이 좋아질 것이라는 것을 알 수 있습니다.
TODO
DB replication 적용
findAll 조회 쿼리 개선 
📈 Load Test
평균 트래픽일 경우와 최대 트래픽일 경우를 나눠서 테스트해보겠습니다. 테스트 시간은 30분으로 진행합니다.
평균 트래픽
VUser: 7
테스트 시간: 30분
최대 트래픽
VUser: 22
테스트 시간: 30분
두 테스트 모두 목표는 아래와 같습니다.
TPS: 11.3 ~ 34 이상
MTT: 50 ~ 100ms 이하
성능 유지 기간: 30분
평균 트래픽 결과
이미 smoke 테스트에서도 문제가 있었던 리뷰어 목록을 조회하는 요청이 거의 2배가 걸리게 되었고, 로그인 요청도 꽤 시간이 늘어났습니다.
Pinpoint로도 살펴보겠습니다.
TeacherFilterRepository 클래스의 findAll()메서드의 문제가 심각하다는 걸 알 수 있습니다.
로그인 과정에서 일어나는 조회쿼리 또한 개선이 필요해보입니다.
최대 트래픽 결과
운영 중 최대 트래픽(가정)일 경우 전반적으로 모든 요청의 시간이 목표를 오버해버렸습니다.. 🤦🏻‍♂️
Pinpoint도 살펴보겠습니다.
당연히 이미 문제가 되었던 쿼리는 더 성능이 안좋아졌고, 새로운 문제도 찾을 수 있었습니다. connection 과정에서 많은 비용이 소모되는 걸 볼 수 있었습니다. 다른 요청들도 모두 시간이 늘어났으므로 모두 확인해보니 findAll과 login을 제외한 요청은 전부 connection에서 비용이 확 증가한 것이었습니다. connection pool도 조정해야겠습니다.
TODO
DB replication 적용
findAll 조회 쿼리 개선 
login 내부 조회 쿼리 개선
connection pool 조정
🛠 개선하기
smoke 테스트와 load 테스트를 통해 개선해 나갈 방향을 잡아보았습니다.
DB replication 적용
findAll 조회 쿼리 개선 
login 내부 조회 쿼리 개선
connection pool 조정
다음 포스팅에서는 개선을 통해 smoke, load 테스트 결과가 어떻게 바뀌는지 알아보겠습니다. 개선을 통해 어느정도 만족할 만한 결과가 나온다면 stress 테스트를 통해 한계점을 찾아보겠습니다.

nGrinder와 Pinpoint를 이용한 성능 / 부하 테스트3 - Smoke 테스트 & Load 테스트

댓글