안녕하세요? 끝까지 강의를 들었는데, 알차고 재미있는 강의였습니다. 강의를 보다보니 레디스를 사용해도 성능적인 차이가 많이 안나는 것을 보고 궁금한 점이 있어서 질문드립니다. 사실 주변에서 캐시로 레디스를 무조건적으로 사용을 하시는 경우를 많이 봤는데요, 제가 생각할때는 결국 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 에서 하는 것이니 갑자기 부하를 높이면 그 수치만큼 실제 부하가 나오지 않을수 있으므로 정확도를 위해 서서히 높이는게 아닐까? 라고 예상하는데 이게 맞는지 , 또 다른 이유도 있는지 궁금합니다.