문제 상황 프로젝트를 진행하면서 외부 API를 사용해야 하는 기능이 있습니다. 해당 API는 깃허브에서 PR(Pull Request의 List)를 조회하는 API입니다. 해당 API는 페이지네이션을 통해 접근해야 하는데요. 공식 문서를 살펴보면 한 번에 최대 100개의 PR만 가져올 수 있습니다. 사실 PR을 모두 조회할 필요는 없었습니다. 요구사항 특성상 많아봤자 한 번에 4~5개 정도의 PR만 조회하면 되었거든요. 하지만 무료 API를 제공하는 서드파티 입장에서도 그렇게까지 구체적인 API를 제공해주지는 않더라고요. 그리고 제공할 책임 또한 없습니다. 그렇다면 사용하는 입장에서는 할 수 없이 모든 PR들을 조회하고, 해당 PR들을 애플리케이션에서 가공해야겠죠. 이 때 PR의 개수가 총 300개라면 최..

지난 글에 집고팀에서 사용하는 쿼리를 살펴보고 개선 방안들을 도출해봤습니다. 이번 글에서는 실제로 코드와 쿼리를 고쳐보고 클라이언트에서 받는 데이터까지 가공하면 어디까지 개선이 가능한지 더 자세히 살펴보겠습니다. Entity보다 DTO를 서비스 코드와 Response 프로퍼티들을 분석해본 결과, 아래와 같은 총 4개의 프로퍼티만 필요로 했습니다. pet_food_id pet_food_name brand_name pet_food_image_url public List findPagingPetFoods( List brandsName, List standards, List primaryIngredientList, List functionalityList, Long lastPetFoodId, int size )..

우아한테크코스 팀 프로젝트를 진행 중입니다. 5차 스프린트 요구사항들 중 아래와 같은 요구사항도 존재했는데요. 서비스에서 사용하는 쿼리를 정리하고, 각 쿼리에서 사용하는 인덱스 설정 서비스에서 사용하는 모든 조회 쿼리와 테이블에 설정한 인덱스 공유 인덱스를 설정할 수 없는 쿼리가 있는 경우, 인덱스를 설정할 수 없는 이유 공유 기존 쿼리를 만들 때 어느 정도 개선을 해오면서 만들었었기 때문에 평소 쿼리에 대한 고민을 많이 해보지도 않았었습니다. 실제로 쿼리 개선이 필요할 만큼 TPS가 높지도 않았고요. 또한 어떤 쿼리가 문제인지 찾아내는 과정을 위한 학습도 되어있지 않았습니다. 그래서 이번 글에서는 아무것도 모르는 상태에서 기존 쿼리를 어떻게 개선해 나갔는지 천천히 정리해나가 보도록 하겠습니다. 이번에 ..

조만간 있는 테코톡을 준비하기 위해서 각 성능 테스트 툴들을 사용해보려고 한다. 그 과정에서 발생하는 문제들과 사용해 본 후 장단점들을 써보려고 한다. 먼저 nGrinder를 사용해 보겠다. nGrinder 구조 nGrinder는 크게 컨트롤러(Controller)와 에이전트(Agent)로 구성되어 있다. 컨트롤러는 관리를 위한 UI와 부하 스크립트 작성, 부하 테스트 설정 등의 기능을 지원하며, 관리한 에이전트들을 승인하거나 테스트를 시작해 부하를 발생시킬 수 있도록 제어한다. 에이전트는 컨트롤러의 명령을 받아 서버에 실제 부하를 발생시킨다. 따라서 컨트롤러를 통해 에이전트에 명령을 내리면, 에이전트는 우리가 작성한 스크립트대로 타깃 서버에 부하를 발생시킨다는 것이다. Install/Excute Con..