서버 성능 테스트에 대해 공부한 내용이다. 목차: 1. 서버 성능 테스트의 종류 2. 주요 용어 3. 좋은 서버 성능이란 1. 서버 성능 테스트의 종류 서버 성능 테스트(Performance Testing)에는 하위에 여러 종류가 있다. 아래 이미지가 이를 잘 보여준다. 이 중에서 보통 많이 수행하는 테스트는 다음 4가지라고 한다. 부하 테스트 (Load Test) — 특정한 부하를 제한된 시간을 두어서 웹 어플리케이션에 이상이 없는지 파악하는 테스트 지속성 테스트 (Endurance Test) — Load Test와 유사하나 오랜 기간 부하를 줘서 하는 테스트. 스트레스 테스트 (Stress Test) — 부하의 임계점을 찾고, 장애상황에서의 시스템 반응을 보고 잘 복구되는지 확인하기 위해 점진적으로 ..
목차: 1. 사용 이유 2. nGrinder란 3. nGrinder vs 다른 툴 4. 내용, 성과 사전지식: https://choibulldog.tistory.com/61 서버 성능 테스트의 종류와 필요 지식 서버 성능 테스트에 대해 공부한 내용이다. 목차: 1. 서버 성능 테스트의 종류 2. 주요 용어 3. 좋은 서버 성능이란 1. 서버 성능 테스트의 종류 서버 성능 테스트(Performance Testing)에는 하위에 여러 choibulldog.tistory.com 1. 사용 이유 북클럽 프로젝트를 공개할 시점이 됐다. 그래서 내 서버가 대략 어느정도 규모의 트래픽을 감당 가능한지 알고싶었다. 내 서버의 성능을 알고 있어야 나중에 사람들이 많아져도 대응할수 있기 때문이다. . . . 사실 나는 a..
-x: 당장 중요하진 않은 내용 3장 Object의 클래스는 재정의 해서 사용하는것이 많음. equals, hashcode, toString, clone, finalize - Comparable.compareTo 는 Object는 아님 아이템 10 equals는 필요할 때만 재정의. 안필요하면 그냥 두는게 더 안전. 필요한 경우: 1. 논리적 비교를 해야하고 2. 상위 클래스에서 equals 를 알맞게 재정의 한적 없음 재정의 규약: 1. 반사성 - 자기 자신과 비교는 항상 참. - x.equals(x) == true 2. 대칭성 - 거꾸로 해도 참 - x.equals(y) == true 면 y.equals(x) == true 3. 추이성 - 삼단논법 만족 4. 일관성 - 멱등성과 비슷 5. null 아..
이렇게 또 나이를 먹어서 24살이 된다. 개인적으로는 정말 안좋은 1년이였다... 근 몇년간 어쩐일로 좀 좋더니 ㅋㅋㅋ 이게 정말 내 인생이란 말인가... . . . 개인적인 삶과는 별개로 공부는 정말 많이했다. 대학에 입학 후 2학년을 마칠때까지 배운것보다 21년 3학년에 6달정도간 배운게 더 많은 기분이다. 한마디로 요약하면, 예전에는 사람들이 만든 프로젝트와 기술 스택을 보면 저게 뭐야? 하는 생각만 들었다. 하지만 이제는 다 할줄은 몰라도 그게 뭔지는 알게되었고, 해본적 있는 것도 많다. 그래서 막연함과 답답함이 사라졌고, 상쾌한? 마음으로 해야할 일에 집중하기 쉬워졌다. 한것들 1. 알고리즘 알고리즘 문제를 풀었다. 이 책을 이용해서 학습했는데, 진짜 자존감 박살나고 싶으면 코딩테스트 공부하면 ..
이 글은 정답이 아닌 개인적인 저의 생각 정리입니다...! . . . 고민 개발을 하다보면 계속 Controller와 Service의 역할에 대한 의문이 들었다. Controller가 Service에 있어야할 비즈니스 로직을 가지고 있게 된다고 생각했기때문이다. (내가 그렇게 했기때문에 그런거지만... ㅠㅠ) 실제로 내가 겪은 구체적인 상황: 어떤 컨트롤러의 post 요청에서 A,B,C 엔티티가 반드시 순서대로 생성된후 저장되어야 한다. (참조관계 때문에 그렇다) 기존에는 컨트롤러에서 A 엔티티 생성 -> AService.createA() 한 후 B, C도 동일한 과정을 거침. 이러니까 컨트롤러가 서비스의 역할을 해버린다고 생각함. 코드: //기존 코드 @PostMapping public Response..
테스트 코드를 잘 써야한다. 서비스 장애를 사전에 방지하고, 품질 좋은 코드를 만들게 되며, 시간을 꽤 들여서 테스트 코드를 작성해도 결국 나중에는 그게 시간을 아끼도록 해주기 때문이다. 무엇보다 중요한건 그래야 면접관이 좋아한다. 그걸 나도 아는데, 솔직히 테스트 코드 쓰는 시간을 좋아한다고는 못말하겠다... 그래도 개판인 내 테스트코드를 개선하는 시간을 가져본다... 솔직한 내 현재 상황: 1. 테스트 클래스 통째로 주석처리함 요구사항 빨리 개발해서 쳐내다가 너무 많이 기능이 추가되고 기획이 수정되서 일부 테스트 통과 안되서 걍 편하게 ctrl + A -> ctrl + ? 눌러버림 마지막 양심으로 postman 보면서 수작업 테스팅함 2. 근거없이 오직 @SpringBootTest 통한 통합 테스트만..
테이블 구조를 변경하였다. 이미 저장된 데이터를 유지하면서 변경된 데이터를 옮기는 작업을 했다. 왜 바꿨냐면, 제3정규화를 위반하여 중복되는 데이터가 많을것으로 생각했기 때문이다. book 테이블은 회원이 고유하게 소유하는 책이다. 책 isbn, name 같은 정보 저장 말고도, 다 읽은, 읽는 중, 읽고싶은 등의 정보를 저장하고, 기획상 book이 post를 여러개 갖고 있어서 회원의 post들 테이블에 접근할때 처음 구분을 해주는 역할을 해준다. 구조 변경 전에 처음 설계할때는 사실 중복될것을 몰랐던건 아닌데, 같은 책 정보 몇개 들어온다고 크게 문제될까? 라고 생각했다. 어차피 별로 중복이 많을것같진 않은데 구조가 복잡해지는게 싫었다. 그런데 개발중에 쌓인 테스트 데이터를 보면서 생각해보니, 사실 ..
beanstalk을 쓰면 업데이트 할때마다 구성요소를 갈아 치운다. 그래서 따로 돌아가는 RDS를 beanstalk으로 생성한 ec2와 직접 연결해줘야한다. 민감한 정보(db/aws configuration)를 깃헙에 그냥 올리면 안되니까, beanstalk 쓰기 전처럼 그냥 ssh 접속해서 인스턴스에 application.yml을 프로파일 구분해서 만들면 되지 않을까? 하고 생각없이 작업하고있었는데, 이 글 맨위에 적어놓은게 생각났다 아 근데 이거 어차피 다 날리는데...? 다른 방법을 찾아봐야했다. 좀 보다보니까 구글에 찾아봐도 잘 나오고, 공식문서에도 나와있다 https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/java-rds.html Ama..
