전체 글

🚀 개요 프로젝트에서 실시간 알림 기능을 구현해야 했다. 초기에 고민하던 중 주기적으로 서버에 요청을 보내는 방식을 택했는데 나중에 알고보니 Short Polling 이라고 불리는 방식이었다. 웹 통신 방식엔 Long Polling과 웹 소켓 방식도 있는데 이 글에서 설명하진 않는다. ⭐ Short Polling 계속 요청과 응답을 반복하는 흔한 방식이다. 주기적으로 요청을 보낸다니 대체 어느 간격으로? 내가 생각한 방법은 5초마다 알림 조회 요청을 보내는 것이었다. 바보가 아닌 이상 이 방법은 동시 사용자가 늘어날수록 요청이 기하급수적으로 비례해 늘어날 것이다. 길게 보면 누가봐도 리소스를 많이 먹는 구조이다. 나는 이렇게 이벤트가 발생해도 바로 안 보내지고 주기적으로 조회해야 하는 방법보다는 서버에서..

🚀 개요 프로젝트 진행 중 관리자 페이지에서 여러 조건으로 기업을 검색해야 하는 API가 필요했다. 동적 쿼리를 안 쓰고 단순히 if문으로 분기처리해서 일일이 쿼리문을 날리도록 할 수 있겠지만 service 랑 repository 단 메서드나 코드가 상당히 늘어나기 때문에 지저분해진다. 조건이 4가지여서 repository에 해당 API를 위한 조회 메소드가 16개나 필요했다. 혹여나 조건이 추가되면 점점 관리하기도 어려워질 것이다. 이러한 단점을 해결하기 위해 JPA 동적 쿼리를 활용하기로 했다. JPA에서 동적 쿼리를 생성하는 방법은 보통 JPQL, Criteria, Specification, QueryDSL 이렇게 4가지가 있다. 또다른 방법으론 JPA가 아닌 MyBatis나 검색 기능 자체를 컴포..

🚀 개요 이전에 부하 테스트를 위한 nGrinder를 설치하기 글을 통해 테스트 툴은 세팅이 미리 끝난 상태이다. 성능 테스트 과정을 좀 더 알아보니 단순히 스크립트 짜기 ➡ 테스트 진행 ➡ 결과 분석 과정이 다가 아니라 테스트 계획 수립 ➡ 시나리오 짜기 ➡ 테스트 진행 ➡ 결과 분석 ➡ 적용 과정을 거친다고 한다. 성능 개선을 위한 테스트 과정을 좀 더 파다보니 생각보다 준비할 것도 많고 고려할 점도 많은 것 같고 이런 부분에 대한 러닝 커브가 걱정돼서 할까 말까 고민하다가 잠 못 이루고 그랬는데 어쨌든 조회할 테이블에 데이터가 누적될수록 당연히 조회 성능은 떨어지기 마련이고 이런 대용량 데이터를 다루는 부분에서 내 쿼리문은 솔직히 많이 형편없다고 생각하는 상황이어서 검색 로직이든 쿼리문이든 개선할 ..

🚀 개요 ⭐ 성능 테스트 (Performance Test) 시스템 구성 요소가 특정 상황에서 어떤 성능을 보이는지 확인하기 위해 수행되는 테스트이다. 제품의 리소스 사용, 확장성 및 안정성도 이 테스트를 통해 검증할 수 있다. 시스템의 전반적인 성능을 평가하고, 최적화할 수 있는 부분을 찾아내는 것이 목적. 그리고 성능 테스트는 부하 테스트와 스트레스 테스트를 포함하는 광범위한 개념이다. ⭐ 부하 테스트 (Load Test) 임계값 한계에 도달할 때까지 시스템의 부하를 지속적으로 꾸준히 증가시켜 시스템의 성능을 테스트하는 것이다. 부하 테스트는 사용자의 수, 트랜잭션의 수 등 다양한 부하 조건을 적용하여 시스템의 처리 능력을 평가한다. 즉, 시스템이 예상되는 사용자 수 또는 트랜잭션을 처리할 수 있는지 ..

🚀 서론 프로젝트 진행 중 데이터 수정 시 PUT, PATCH, DELETE를 어느 상황에서 사용해야 되는지 잘 모르고 API를 구현했습니다. 덕분에 프론트엔드님들이 헷갈리신다고 😂😂 (왜냐하면 우린 삭제도 논리적으로 상태만 삭제로 변경하기 때문입니다. 물리 삭제는 일부만 구현한 상황입니다.) 그래서 다시 전체적으로 수정과 삭제 API들을 건드리게 되었습니다. 작업하면서 공부한 내용을 소개하겠습니다. ⭐ PUT과 PATCH 구분하기 PUT, PATCH를 수정 용도로 사용한다고만 알고있어서 차이를 잘 모르고 혼용해서 막 쓰는 경우가 종종 있습니다. 결론부터 말하면 둘은 엄연히 다릅니다. 개쪽이: PUT 요청이든 PATCH 요청이든 결과가 같은데요????? 개쪽아. 그것은 결과만 그렇게 보일 뿐 둘은 대체재..