api를 제가 개발했다고 가정하겠습니다. 이 기능에는 외부 api 호출이 포함되어 있습니다. 그러면 api를 어떻게 테스트할 수 있을까요 ?? 과금 문제나 타사의 api 를 무차별적으로 호출해 성능테스트 하면 여러 문제가 있을 것 같습니다. 예를들어 실시간계좌이체를 위해 금감원이나 금결원의 api를 연동하는 경우나, 소셜로그인 등을 위해 네이버, 카카오의 api를 연동하는 경우, 타사에서 제공해준 api 호출이 포함된 기능을 개발하는 경우가 될 것입니다. (물론 타사에서 호출은 일정 수준으로 제한하는 등 여러 가이드를 보내주겠지만 이런게 없다고 가정합니다) wiremock, mockserver같은 여러 방법들을 찾아보았지만 이는 테스트코드 기반의 테스트방법이고 외부 연동이 성공적으로 연동되었음을 테스트할 수는 있지만 성능테스트에는 부적절하다고 생각되는데, 성능테스트를 하기 위해서는 적절한 방법이 있을까요 ?

안녕하세요. 개발 서버가 현재 https 로 돌아가고 있는데1) artillery target 입력 - https 이 때 결과가 NaN 만 뜨고 테스트 작동이 안 됩니다 ㅠㅠ (톰켓 로그를 보면 artillery 작동 로그가 안 찍힙니다.) 2) target - http 입력이 때는 artillery 가 테스트 실행해주는데 302 에러가 계속 나옵니다.(이때는 톰켓 로그에 artillery 가 실행된 결과가 있음) 어떻게 해야 할까요? ㅠ

안녕하세요!DB가 붙어있는 서버에 post 메서드의 테스트를 진행하고있습니다.api의 내용은, 데이터를 생성하는 작업을 진행합니다. 문제는, 테스트를 진행 후에 테스트를 위한 데이터가 생성되어 이 데이터를 삭제해줘야 하는 부분이 문제가 되고 있습니다.몇가지 가정을 하면 배포되어있는 서버에 테스트를 진행하는 상황이고, 별도의 테스트용 db는 아직 구성해놓지 않은 상태입니다. 실제 성능 테스트를 진행할 때에는, 테스트용 서버에 배포를 해두고, 테스트용 db를 따로 구성해둔 상태로 진행해야 되는건가요? 이 때 테스트서버의 성능은 배포 서버와 최대한 비슷하게 구성하나요?만약 테스트 후 더미데이터를 삭제해야하는 경우가 발생하면 (성능 테스트간 독립성 확보 목적 등), 어떤식으로 롤백을 시켜주는것이 좋을까요? 1. 당장 드는 생각은, SSH 접속을 하여 DB의 내용을 정리하는 스크립트를 작성하여 artillery의 after 스크립트에 작성해서 추가해준다.2. 이런 상황이 발생하지 않도록 애초에 테스트간 영향이 없도록 구성한다. 

안녕하세요. 강의 잘 듣고 있습니다 🙂. Vultr Payment로 등록할 카드가 알 수 없는 이유로 거절되고 있습니다. AWS EC2, RDS로 실습을 대체해도 문제가 없을까요?

성능 테스트 스크립트config: target: 'http://localhost:8080' phases: - duration: 30 arrivalRate: 20 name: Warm up - duration: 10 arrivalRate: 20 rampTo: 2000 name: Ramp up load - duration: 10 arrivalRate: 2000 name: Sustained load - duration: 30 arrivalRate: 2000 rampTo: 20 name: End of load scenarios: - name: "high load cpu" flow: - get: url: "/high-load-cpu" - name: "high load memory" flow: - get: url: "/high-load-memory"실행결과Started phase 0 (Warm up), duration: 30s @ 15:00:57(+0900) 2024-09-29 Report @ 15:01:07(+0900) 2024-09-29 Elapsed time: 10 seconds Scenarios launched: 199 Scenarios completed: 199 Requests completed: 199 Mean response/sec: 20 Response time (msec): min: 1 max: 324 median: 48 p95: 53.5 p99: 296 Codes: 200: 199 Report @ 15:01:17(+0900) 2024-09-29 Elapsed time: 20 seconds Scenarios launched: 200 Scenarios completed: 200 Requests completed: 200 Mean response/sec: 20 Response time (msec): min: 1 max: 164 median: 48 p95: 49 p99: 118.5 Codes: 200: 200 Report @ 15:01:27(+0900) 2024-09-29 Elapsed time: 30 seconds Scenarios launched: 200 Scenarios completed: 200 Requests completed: 200 Mean response/sec: 20 Response time (msec): min: 1 max: 185 median: 3 p95: 50.5 p99: 146 Codes: 200: 200 Started phase 1 (Ramp up load), duration: 10s @ 15:01:27(+0900) 2024-09-29 Report @ 15:01:37(+0900) 2024-09-29 Elapsed time: 40 seconds Scenarios launched: 1379 Scenarios completed: 1330 Requests completed: 1330 Mean response/sec: 137.9 Response time (msec): min: 1 max: 878 median: 63 p95: 481 p99: 730 Codes: 200: 1330 Report @ 15:01:47(+0900) 2024-09-29 Elapsed time: 50 seconds Scenarios launched: 1884 Scenarios completed: 1841 Requests completed: 1841 Mean response/sec: 189.35 Response time (msec): min: 2 max: 2192 median: 389 p95: 1435.9 p99: 1679.5 Codes: 200: 1841 Report @ 15:01:57(+0900) 2024-09-29 Elapsed time: 1 minute, 0 seconds Scenarios launched: 1938 Scenarios completed: 1921 Requests completed: 1921 Mean response/sec: 197.05 Response time (msec): min: 2 max: 2391 median: 553 p95: 1766 p99: 2121.3 Codes: 200: 1921 Report @ 15:02:07(+0900) 2024-09-29 Elapsed time: 1 minute, 10 seconds Scenarios launched: 1999 Scenarios completed: 1825 Requests completed: 1825 Mean response/sec: 200.2 Response time (msec): min: 3 max: 3944 median: 951 p95: 2591.8 p99: 2944.8 Codes: 200: 1825 Report @ 15:02:17(+0900) 2024-09-29 Elapsed time: 1 minute, 20 seconds Scenarios launched: 2051 Scenarios completed: 1920 Requests completed: 1920 Mean response/sec: 203.88 Response time (msec): min: 275 max: 4463 median: 1762.5 p95: 3452 p99: 3868.6 Codes: 200: 1920 Errors: ETIMEDOUT: 15 Started phase 2 (Sustained load), duration: 10s @ 15:02:25(+0900) 2024-09-29 Report @ 15:02:27(+0900) 2024-09-29 Elapsed time: 1 minute, 30 seconds Scenarios launched: 2352 Scenarios completed: 1754 Requests completed: 1754 Mean response/sec: 228.47 Response time (msec): min: 729 max: 5593 median: 2867.5 p95: 4719.8 p99: 4972.5 Codes: 200: 1754 Errors: EPIPE: 1 ECONNRESET: 8 ETIMEDOUT: 200 Report @ 15:02:37(+0900) 2024-09-29 Elapsed time: 1 minute, 40 seconds Scenarios launched: 5182 Scenarios completed: 1679 Requests completed: 1680 Mean response/sec: 522.91 Response time (msec): min: 2409 max: 8590 median: 5161.5 p95: 7927 p99: 8578.7 Codes: 200: 1680 Errors: ETIMEDOUT: 235 ECONNRESET: 67 Report @ 15:02:47(+0900) 2024-09-29 Elapsed time: 1 minute, 50 seconds Scenarios launched: 2948 Scenarios completed: 322 Requests completed: 321 Mean response/sec: 294.51 Response time (msec): min: 7959 max: 9752 median: 8775 p95: 9748 p99: 9750 Codes: 200: 321 Errors: ETIMEDOUT: 3978 ECONNRESET: 45 Report @ 15:02:57(+0900) 2024-09-29 Elapsed time: 2 minutes, 0 seconds Scenarios launched: 3922 Scenarios completed: 0 Requests completed: 0 Mean response/sec: 392.2 Response time (msec): min: NaN max: NaN median: NaN p95: NaN p99: NaN Errors: ETIMEDOUT: 2937 ECONNRESET: 434 EPIPE: 2 Report @ 15:03:07(+0900) 2024-09-29 Elapsed time: 2 minutes, 10 seconds Scenarios launched: 3060 Scenarios completed: 0 Requests completed: 0 Mean response/sec: 304.17 Response time (msec): min: NaN max: NaN median: NaN p95: NaN p99: NaN Errors: ETIMEDOUT: 3260 ECONNRESET: 389 우선 30초까지는 Warm up 단계로 요청을 잘 처리한거 같습니다. 그 다음 Ramp up load 단계는 10초 동안 초당 20개에서 초당 2000개로 늘렸는데 실제 터미널 콘솔에 찍힌걸 보면 Scenarios completed: 1000 Requests completed: 1000 이렇게 나와 있습니다. 저는 최소 2000개 요청을 보냈는데 저렇게 찍힌걸 보면 40초까지 1000개만 처리 완료했지만 실제로는 요청이 더 온 상태고 해당 요청에 대해서는 처리를 완료하지 못한 상태라고 해석하면 될까요?Sustained load 단계에서는 10초 동안 초당 2000개의 요청을 계속 보내는 상태인데요 그럼 10초 동안 총 20000개의 요청이 가야하는데 실제 실행 결과를 보면 10초 동안 20000개의 요청을 처리하지 못하고 계속해서 요청을 처리하다가 나중에는 거의 처리를 하지 못하는 상태에 오는데요 이 부분은 서버에 요청을 처리할 자원이 거의 없는 과부하 상태라고 해석하면 될까요?  

안녕하세요.몇가지 질문사항이 있어 문의 드립니다. 파라미터 테스트를 .csv 파일을 사용하여 로드하여 사용하는 것을 예제로 들어주셨습니다. 이 때, body에 적용되는 값은 .csv 파일의 랜덤한 값이 들어가는 것 같은데, 테스트에서 이렇게 값을 의도하는 이유가 있을까요? 당장 드는 생각은, (동일 데이터를 반복 테스트 하였을때, 캐싱이 되어잇다면, 확실한 성능 테스트 확인이 불가능 할 수 있다) 정도가 생각이 듭니다.어느정도의 데이터를 .csv파일에 등록해서 테스트 하는 것이 좋을까요? 당연히 테스트 하는 케이스별로 다르겠지만, 테스트 하실때 적용하시는 간단한 예시를 들어주시면 좋을 것 같습니다. EX) 요청 건수의 ??% 정도

처음에는 초당 요청 횟수 x 시나리오수로 총 요청이 온다 고 이해를 했는데 다른 분 질문글을 읽어보니 제가 이해한게 맞나 싶어서 질문합니다.30초당 3개의 요청을 보내고 시나리오에 2개의 flow가 있다고 했을때 1번 flow는 3개의 api 그리고 2번 flow는 1개의 api라고 한다면 30 초당 3개의 요청을 보내는 횟수인 90개의 요청에서 몇개는 1번 flow 몇개는 2번 flow의 api를 서버로 보내는건지 궁금합니다.

안녕하세요? 끝까지 강의를 들었는데, 알차고 재미있는 강의였습니다. 강의를 보다보니 레디스를 사용해도 성능적인 차이가 많이 안나는 것을 보고 궁금한 점이 있어서 질문드립니다. 사실 주변에서 캐시로 레디스를 무조건적으로 사용을 하시는 경우를 많이 봤는데요, 제가 생각할때는 결국 I/O대기시간이 일반적인 api에서 큰 부분을 차지하고, 결국 레디스라는 것도 IO를 기다려야 하는 것은 동일하지 않나요? 그렇게 따지고 보면 강의에서 보여주신 것처럼 레디스를 사용하더라도 성능적 차이가 많이 안나는 경우가 꽤나 빈번할 것 같은데, 강사님의 의견이 궁금합니다. 레디스 내에서 해시값을 기반으로 데이터를 조회하는 속도야 빠르겠지만, 애초에 요청받았을 때 수행해야하는 [작업] 그 자체의 비중보다 [IO]를 대기하는 시간이 큰 경우가많은, 예를 들면 DB에서 단순히 레코드한줄을 조회한다든지 하는 기능이라고 하면 레디스를 쓰는 건 비용까지 고려했을 때 굳이 할 필요가 없는 선택처럼 느껴집니다.결국 레디스는 IO보다 요청에 따라 수행해야 하는 작업 그자체의 크기가 조금 클때 그제서야 유의미해 보이는데 어떻게 생각하시는지 의견이 궁금합니다! 추가로 강의 잘들었습니다. 혹시 다음 강의는 언제쯤 출시할 예정이신지 알 수 잇을까요?

안녕하세요? 강의쭉 잘 듣고 있습니다.강의에서 말씀해주시고자 하는 부분은 [IO대기시간이 있는 작업을 비동기로 돌려서 클라이언트쪽에 우선응답을 빠르게 주고, 나머지는 따로 알아서 처리하는 것]으로 이해했습니다. 말씀해주신 방법은 충분히 사용할 수 있는 방법이라고 생각합니다. 그런데 조금 논외로, 이렇게 분리하는 방식이 좋은 방향성인가?에 대해서 궁금증이 생기고 사실 이 부분에 대해 최근 현업에서도 꽤 고민하고 있어서 질문을 드립니다. 아무래도 쪼렙 주니어개발자다보니.. 이런 부분에서 부족함과 의문이 많이 있네요 ㅠㅠ 제 생각에, 단축 url을 만드는 api가 200을 내려준다고하면 저장까지 올바르게 완료됨을 전제해야한다고 생각합니다. 이렇게 생각하는 이유는, 단축 url을 저장하는 것까지가 일종의 핵심적인 로직에 포함되지 않나? 하는 생각입니다. 예를 들어 로그를 찍거나, 혹은 비즈니스로직이여도 그렇게 중요하지 않은 부분이라면 마음편하게 완료를 보장하지 않는 async로 돌려도 될것 같습니다.하지만 url저장처럼 핵심적인 로직에 관한 부분에 대해서는 200을 내려줄 거면 저장도 올바르게 보장되어야 하지 않나? 하는 생각이 듭니다. 다르게 말하면, 내려준 단축 url이 정상적으로 동작하지 않는데 200을 내려줘도 되나? 에 대한 궁금증입니다.(물론 핵심적인 로직에 대한 판단은 개개인마다 또 상황마다 다를 수 있지만요) 결론적으로 여쭤보고 싶은 부분은 아래와 같습니다1) 비동기로 나누는 부분의 기준이 강사님에게 있으실 것 같은데, 보통 어떤 기준으로 나누시나요?2) 추가로, 핸들링을 어떤식으로 하시는지도 궁금합니다. 예를 들면 위와 같이 저장하는 로직을 비동기로 뺏을 때, 실패한다면 보통 어떤식으로 핸들링을 하시나요?

안녕하세요? 좋은 강의 감사드립니다. 몇가지 질문이 있어서 여쭤봅니다. 1.시나리오 작성해서 테스트하기 강의 11분 즈음에 보면,요청 개수가 184개고 이게 요청 개수 90 시나리오 개수 2에서 나온거라고 말씀하시면서시나리오가 여러 개면 요청 개수 * 시나리오 개수만큼 요청이 된다고 해주셨습니다.그런데, 요청은 분배되는데 첫번재 테스트는 api가 한개이고, 두번째 테스트는 api가 3개라 결과적으로 180 언저리의 값이 나오는 거 아닌가 싶어서여쭤봅니다. 실제로 강의 영상에서도 시나리오 카운트에서 43, 47로 90이 나뉘고43 1 + 47 * 3해서 184가 나오는 것이 아닌가결과적으로 요청은 시나리오 개수만큼 분리되는 것 아닌가 싶어서 질문드립니다.2. 강의 중에, 실제로 사내에서는 ngrinder를 사용하고 계시다고 말씀하셨는데, 혹시 최신버전의 artillery를 사용해보셨는지 그럼에도 불구하고 여전히 ngrinder를 사용하시는 게 편하신지가 궁금합니다..artillery 최신버전을 써보니 간편하게 사용할 수 있는 게 너무 마음에 들어서 손에 익혀두면서 사용해보고 싶은 마음이 있습니다.하지만 ngrinder를 보통 사내에서 쓴다면 가능하다면 ngrinder를 익혀두는 게 더 좋지 않을까 싶어서 ㅎㅎ.. 의견을 구해봅니다.아니면 혹시 artillery가 ngrinder에 비해 부족한 부분이 있는지도 궁금합니다. 

1.이런식으로 나오는데 서버 성능을 올려줘야할까요..?2. 이해한바로는 Scenarios completed : 요청에 대한 응답이 정상적인 개수인데 만약 저렇게 대규모 요청이 왔을때 이런 서버를 유지한다면 유실된 응답수만큼 요청한 사용자가 응답을 못받는거 맞나요?!ec2 프리티어를 사용중입니다.config:target: 'https://onsuho.store' phases:- duration: 10arrivalRate: 5- duration: 10arrivalRate: 20- duration: 30arrivalRate: 100- duration: 10arrivalRate: 20scenarios:- flow:- get:url: "/hello"

안녕하세요 강사님해당 강의에서 postman 으로 /high-load-cpu GET 요청을 보냈을 때 첫번째 요청은 134ms 가 걸리고 2번째 요청 이후부터는 30대의 ms 가 걸리는 것을 보여주셨는데요.이게 첫번째 요청과 2번째 이후부터의 요청의 latency 가 다른 이유가 무엇인가요?이전에 사이드프로젝트를 진행하며 latency 측정할 때도 비슷한 현상이 있었습니다. (동일한 API 에 대한 요청인데 첫번째 요청만 오래걸리고, 두번째부터는 훨씬 빠르게 처리됨)첫 요청 및 응답 이후에는 2번째 때부터 요청/응답 하는 과정에서 달라지는 부분들이 있는건가요?이후 강의를 듣다보니 첫번째는 웜업 과정 때문에 오래걸린다고 말씀하시네요.. ㅎㅎ 그렇다면 보통 평균 속도를 측정한다고 하면 1번째는 제외하고 2번째 응답 속도부터 n 번째 응답 속도까지의 평균을 계산하는 게 맞다고 보면 되나요?

성능테스트 하게 되면 test-config.yml 파일과 report.json , report.html 파일을 git 에 올리는 편이신가요 ?? 아니면 삭제를 하시거나 gitigrnoe 에 추가하시나요 ?

터미널 명령어를 통해서 report.html 파일 생성까지 완료되었습니다. 근데 위 사진처럼 404 에러가 발생했습니다.아래에 html 코드 윗부분만 첨부해서 올립니다.html 파일 외에 어떤걸 확인해야 하는지 알려주시면 확인해 보겠습니다. 

안녕하세요. 강사님 좋은 강의 즐겁게 수강하고 있습니다!제가 생각하는 부하테스트라는게 유저가 동시에 몰릴 수 있는(ex 예매, 상품 구매, 검색 등) API에 필요하다고 생각하는데,그 외에 유저 자기 자신만 접근할 수 있는 API도 있을텐데, 그런 API도 부하테스트가 필요한건지 궁금합니다!

ramp to 를 통해 서서히 부하가 올라가게 하고, 서서히 부하가 내려가도록 시나리오를 구성하셨는데, 실무에서도 이런식으로 구성하는걸 봤습니다.제 생각에는 부하발생하는 것도 app 에서 하는 것이니 갑자기 부하를 높이면 그 수치만큼 실제 부하가 나오지 않을수 있으므로 정확도를 위해 서서히 높이는게 아닐까? 라고 예상하는데 이게 맞는지 , 또 다른 이유도 있는지 궁금합니다.