부하 테스트 지난번에 진행했던 부하테스트는 처음이었기도 하고, 객관적인 분석을 하기가 여러모로 힘든 결과 데이터 같아서 다시 진행해보려 한다. 다음과 같은 설정으로 컨테이너에 1메모리를 할당하였고, 1코어의 CPU를 할당하여서 리소스를 제한시켰다. docker ru

LikeLion 리크루팅 개발에서 커뮤니티 기능을 맡게 되었다.60여개 학교의 학생들이 사용할 예정인 만큼 성능 개선이 매우 중요하다고 생각되었다.게시글 조회 기능에 대한 성능을 고민하고 있었는데, 이전에 사용했던 제로 오프셋 방식을 도입하고자 했다.제로오프셋 방식 최

2차 스프린트에 앞서 간단하게 리팩토링을 진행했다.기존의 코드는 다음과 같이 Raw 타입으로 반환하고 있었다. ResponseEntity에 들어갈 body가 어떤 타입이든 상관이 없었는데, 이것이 문제가 될 것 같아 수정해주었다. 이와 비슷한 경험은 이전에 NOTODO

https://velog.io/@chs98412/Django-%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%A0%88%EC%9D%B4%EC%96%B4위 포스팅에서 장고 어플리케이션 안의 서비스 로직을 분리시키는 과정을 작성했다.현재 코드에서는 서비스

django로 프로젝트를 진행할 때, 항상 궁금했던 점이 있었다.django와 springboot가 하는 일은 사실 같은 일인데, 스프링부트에서 볼 수 있었던 구조를 django에서는 볼 수 없었다는 점이다.기본적으로 springboot에서는 repository 레이어

.

.

처음에 구상한 아케텍처는 다음과 같았다.쿠버네티스를 이용하고, hpa를 통해 트래픽이 늘어나면 pod를 증가시키는 식으로 부하를 분산하고 싶었다.그래서 미니쿠베로 쿠버네티스도 공부해보고,eks로 클러스터도 구성해봤는데 생각보다 많이 어려웠다.구글링해가면서 하면 어찌저찌

내 어플리케이션이 얼마나 뛰어난 성능을 갖고 있는지, 혹은 얼마나 안좋은 성능을 갖고 있는지 알기 위해 그라파나 + 프로메테우스 + Jmeter 구성을 갖고 실험해보았다.클라우드 상에서 테스트를 하면 N백만원이 과금될수도 있기 때문에 로컬상에서 진행했다.적당..하다고

테스트 코드를 작성하다가 기존 코드가 잘못되었음을 알았다.위 코드는 게시글을 수정하는 메소드이다.헌데 수정을 하고 ArticleDTO를 반환하는 과정에서 ArticleDTO.Response.builder()의 인자가 수정된 게시글이 아니라 기존에 수정하고 싶은 게시물을

현재 서비스 레이어에서 중복되는 코드가 있어서 고쳐보려고 한다.고치는 김에 조금 불편함을 느꼈던 부분들도 같이 고쳐보고자 한다.중복되는 코드는 아래 두개이다.두 메소드 모두 id를 기준으로 Product를 찾아오는 기능을 한다. 다만 하나는 컨트롤러에서 호출하기 때문에

작성한 코드는 다음과 같고응답시간은 네이티브 쿼리를 사용했을 때와 비슷하게 가용한 수준으로 나온 것을 알 수 있다.실제 실행된 쿼리는 위와 같다.네이티브 쿼리와 비교해보겠다.네이티브 쿼리를 이용하였을 때QueryDsl을 사용했을 때거의 동일한 쿼리가 나갔음을 알 수 있

엔티티간의 어노테이션을 통한 연관관계를 지우고 외래키를 지정해주었다.쿼리는 다음과 같이 작성했다.테이블의 모든 정보를 가져오는게 아닐 때에는 이렇게 인터페이스로 가져와야 한다고 한다.(키워드: 프로젝션)결과는 이렇게 속도도 개선되고, 쿼리도 원하는 만큼만(인증, 조회

Article을 살펴보면이렇게 ManyToOne으로 Member를 갖고 있다.게다가 페이지 당 10건의 Article을 가져오기 때문에 페이징에 필요한 쿼리에다 추가로 10개의 쿼리를 날리는 것으로 보인다.N+1 문제는 예전 글에서 살펴봤던 것 처럼 페치 조인을 사용하

페이징 해주는 메소드를 실행했다. 실행되는 쿼리는 다음과 같다. (아직 N+1 문제를 해결하지 않은 상태이다.)첫번째 줄은 이전 포스팅에서 알아본 인증 관련된 쿼리이다.두번째 줄인는 페이징을 위해 나간 쿼리이고마지막 줄인도 페이징에 필요한 카운트 쿼리이다.그 사이의 1

전체 쿼리이다. 메소드 하나에서 출력되는 쿼리인데, 너무 많은 쿼리가 날라가는것 같아서 개선해보고자 한다.먼저 맨 위의 두 줄을 해결해보려 했다.맨 위의 두 줄은 인증시에 날아가는 쿼리이고, 인증시에 이렇게 쿼리가 두번씩 나가는 이슈가 있었다.왜 두 번 실행 되는지 궁

많은 SNS에서 댓글을 먼저 보여주고 대댓글을 나중에 보여주는 데에는 이유가 있다고 생각되고, 심지어는 댓글만 띄워도 페이징을 사용하는데, 댓글과 대댓글을 한 번에 불러올 생각을 했다는게 쪼끔 성급했던 것 같습니다...그리고 댓글과 대댓글을 합치는 것이 둘이 같은 기능

기능이 완성되면 Postman으로 확인하는 방식을 사용했다. 그러다보니 소셜 로그인이 연결되어 있는 경우, 클라이언트 어플리케이션도 작동시켜서 로그인을 진행하고, 작성한 기능까지 도달하기 위한 선행작업을 진행했다. (예를들어 댓글 쓰기 기능이면 게시글이 선행되어야 함)

N+1 문제를 알아보았다.먼저 N+1 문제가 발생하는 시점을 알아보자.다음과 같이 한 엔티티에 ManyToOne으로 연관관계가 설정되어 있는 상황이다. FetchType.Lazy로 지연로딩이 설정되어 있다. 지연로딩이 되어 있으면 .getMember()를 하는 시점에