spring boot 사이드 프로젝트 : 테스트 시나리오를 세우고 jmeter를 통해 부하 테스트 해보기

프로젝트를 배포, 운영해보면서 내 프로젝트에 어디서 병목 현상이 발생하는지, 트래픽은 어느 정도까지 감당할 수 있는지 확인이 필요한 경우를 공부한 과정입니다. 테스트하는 프로젝트는 sns 사이드 프로젝트로, 간단히 포스팅을 쓰고, 댓글 및 좋아요가 가능한 기본적인 커뮤니티입니다. 테스트는 다음과 같이 시나리오를 설정하고, 진행했습니다. 테스트 시나리오 구성 근거 실제로 클라우드에 배포하는 건 돈 때문에ㅜㅜ 제 컴퓨터 스펙의 서버를 기준으로 잡고 일단 테스트 기준을 세웠습니다. 1. 서버 스펙 제 컴퓨터 스펙은 다음과 같습니다. cpu : AMD Ryzen 5 3500X 6-Core Processor 3.59 GHz (6코어 입니다.)메모리 : 16GBdisk : sdd 500GB 2. ..

개인 프로젝트 2025.02.20 0

spring boot : entity <-> dto 변환 방법에 대한 고민( MapStruct 에 대해)

개요프로젝트를 진행하며 여러 layer사이에 데이터를 전달할 때, dto, entity 간 변경이 자주 일어나는 상황에 변환하는 코드를 일일이 적어넣는 것이 불편했습니다.   예시로 보면, member  한 명을 생성하는 post api는 다음처럼 작성되어 있었습니다.  @Controller@RequiredArgsConstructorclass MemberController { private final MemberService memberService; @PostMapping() public Member createMember(@RequestBody MemberDto memberDto){ //dto 사용 Member member = memberService.createM..

spring boot 2024.10.09 0

[ 프로그래머스 lv 2 ] 2개 이하로 다른 비트 (c++)

문제 풀이 처음에 생각한 풀이방법은 xor 비트 연산을 이용하는 것이었다. 문제 예시로 7과 8 사이의 다른 비트 개수를 셀 때 xor를 사용하면 4개라는 사실을 쉽게 알 수 있었기에 그런 생각이 들었다. 문제는 xor을 이용해서 numbers[i]보다 큰 수들을 차례로 찾아가니 시간 초과가 발생했다. 문제에서 numbers의 최대 원소 크기는 10의 15승으로, 반복문을 30번 정도로 설정해도 한 번 xor 비트 연산 시 꽤 많이 비교하는 작업이 발생했다. 이 때문에 numbers의 길이 100000 x 반복문 대략 50번 (bit를 1씩 왼쪽 쉬프트 연산하며 1 개수를 셈) x 내부에서 비트 연산 횟수 (xor 연산하는데 걸리는 시간) 을 계산하면 1억을 넘어가게 되었다... 그래서 다른 방법을 찾아..

프로그래머스 2023.11.28 0

spring boot jpa : soft delete 구현 (delete 후 데이터 복원)

데이터를 삭제할 때 DB에서 완전히 삭제되는 방식은 사실 프로젝트를 운영해 나갈 때 좋은 방식이 아니다. 누군가 데이터를 실수로 삭제했을 때 복구하려면 DB에 어떤 방식이든 데이터를 남겨둬야 했다. 그렇기에 데이터를 복구하는 방법을 찾아보니, soft delete라는 방식을 통해 데이터 삭제를 하는 방법이 있었다. soft delete란? 데이터를 삭제할 때 두 가지 방식 중 하나다. hard delete, soft delete가 있다. hard delete : 실제로 db에 delete쿼리를 날려 데이터를 삭제하는 것. soft delete : 실제로 삭제하는 것이 아니라, 테이블에 deleted_check 같은 필드를 추가해서 그 데이터가 삭제처리 되면 삭제가 아니라 deleted_check만 바꿔주..

spring boot 2023.09.06 0