전체 글 (104) 썸네일형 리스트형 2024-01-30 오늘은 프로젝트 27일차이다. 오늘은 어제 진행했던 ngrinder의 문제를 해결하기 위해 아침부터 분주하게 했으나 하다가 답이 안 나와서 전부 리셋을 하고 진행했다. 리셋하고 처음부터 도커에 설치를 하고 시작을 하니 전에 입력했던 명령어를 드디어 윈도우 볼륨이 아닌 리눅스 볼륨으로 입력해도 잘 생성 됐다. 생성을 하고 나서 기분 좋게 테스트를 진행해 봤다. 초기 테스트를 진행하기 위해서 스크립트를 작성해야 된다. 아래는 테스트 코드이고 여기서 본인테스트에 맞게 수정을 진행하면 된다. import static net.grinder.script.Grinder.grinder import static org.junit.Assert.* import static org.hamcrest.Matchers.* impo.. 2024-01-29 오늘은 프로젝트 26일 차이다. 오늘은 서비스 배포를 진행하면서 기다릴 시간이 없기 때문에 부하테스트를 진행하기 위해 ngrinder 환경구축을 진행했다. 테스트 환경을 구축하기 위해 처음에는 ngrinder공식 홈페이지에 가서 war파일을 받았다. https://github.com/naver/ngrinder/releases Releases · naver/ngrinder enterprise level performance testing solution. Contribute to naver/ngrinder development by creating an account on GitHub. github.com 받은 파일을 통해 window cmd에서 받은 파일의 디렉토리로 이동하고 아래의 명령어를 통해 실행을.. 2024-01-26 오늘은 프로젝트 23일 차이다. 오늘은 어제 진행하던 내용에서 N+1문제를 해결하기 위해 기존에 커서기반의 공연 전체조회 기능의 쿼리를 수정했다. 여기서 N+1문제가 발생할만한 이유는 goodsInfo에 goodsImage가 양방향 매핑으로 설정 돼 있는 동시에 Laze의 설정 때문에 발생하는 것으로 원인 추축이 된다. 수정을 위해 기존의 쿼리에서는 이미지를 쿼리 처리가 끝난후에 가져온 이미지 중에서 서비스 로직을 통해 대표 이미지를 분리해서 넣었었다. 이번에 개선한 점은 이미지를 개선과 동시에 DTO를 생성하여 필요한 데이터만 쿼리로 바로 처리하게 뜸했다. GoodsImage의 서브쿼리를 생성하고 서브쿼리에서 Dto에 필요한 객체를 매핑하여 goodsid, title, 이미지는 내부 서브 쿼리를 다시 .. 2024-01-25 오늘은 프로젝트 22일 차이다. 프로젝트를 진행하면서 기존에 메인페이지에서 조회하는 공연 전체 조회를 성능 최적화 하기 위해 준비했다. 오프셋 페이지네이션에서 성능 최적화를 하면서 Page방식에서 커서 방식으로 변경했기 때문에 기존에 있던 코드와 비교를 진행했다. 그러기 위해서는 AOP를 추가해야 하는데 다음과 같이 추가했다. 이 AOP는 쿼리가 실행되는 시간을 보여준다. package com.sparta.ticketauction.global.aop; import org.aspectj.lang.JoinPoint; import org.aspectj.lang.annotation.After; import org.aspectj.lang.annotation.Aspect; import org.aspectj.lang.. 2024-01-24 오늘은 프로젝트 21일 차이다. 오늘은 서비스 론칭을 하기에 앞서서 조회기능 향상을 위해서 기존에 사용하던 오프셋 기반의 페이징 조회가 아니라 커서 기반의 조회를 구현을 진행했다. 커서기반의 조회를 구현할라면 커서 Id와 사이즈가 필요하다 커서 Id는 현재 보고 있는 공연의 위치와 같으며 사이즈는 조회 시 현재 위치하고 있는 커서에서 어디까지 조회를 진행할 건지 나타내는 기능을 한다. 또한 기존의 카테고리 이름을 받아서 필요한 카테고리에 따라서도 조회가 가능하게끔 했다. 실제로 구현한 코드는 다음과 같다. @GetMapping("/goods") public ResponseEntity getAllGoods( @RequestParam(value = "cursorId", required = false) Lon.. 2024-01-23 오늘은 프로젝트 20일차이다. 오늘은 따로 진행한 사항은 없다. 어제 프로젝트 발표를 끝나고 오늘까지 팀원과 잠시 휴식시간을 갖기로 했다. 배포한 서비스 웹페이지를 사용해보고 유저가 만족했던부분, 만족하지 못한 부분에 대해서 피드백을 받아보고자 설문조사를 진행할 예정이다. 아래는 설문지이다. 내일부터는 조회에 관련된 기능의 최적화를 통해 쿼리의 응답속도 개선을 해볼 예정이다. 2024-01-22 오늘은 프로젝트 19일차이다. 오늘은 중간발표가 있는 날이였다. 중간발표를 하기 위해 주말동안 프론트를 테스트를 진행하면서 시간을 보냈고. 내가 담당한 파트의 부분은 전부끝났지만 팀원들의 파트가 끝나지 않았기 때문에 팀원들의 파트를 도와드리면서 최대한 마무리에 신경썼다. 다음은 프로젝트를 진행하면서 튜터님들이 프로젝의 전반적으로 살펴보시고 질문 주신것에 대한 답변 내용이다. 1. 특정 경매가 인기가 좋아 트래픽이 많이 발생했다면 어떤식으로 대응 할 계획이신가요? - 기본적으로 트래픽이많아 서버의 CPU 로드율이 높아지면 AutoSaciling 설정을 통해 추가 ec2 인스턴스를 배포할 계획입니다. - DB, Redis 의 경우에도 RDS, Elastic Cache의 클러스터 설정으로 동적으로 노드를 늘려.. 2024-01-19 오늘은 프로젝트 16일차이다. 오늘도 어제와 마찬가지로 프로젝트 와이어프레임으로 기반한 프론트 구성을 진행했고 오늘 담당한 모든 프론트 페이지를 전부 구현했다. 구현한 페이지는 공연장 생성페이지, 공연 정보 생성 페이지, 공연 생성 페이지, 등급 생성 페이지, 구역 등급 생성페이지, 경매 생성 페이지, 공연 단건 조회 페이지까지 총 7개의 페이지를 구현하였으며 오늘 경매 생성페이지를 구현을 마치고 테스트까지 완료했다. 경매 생성 페이지를 만들다 보니 검증해야할 부분이 많아서 시간이 오래걸렸다. 첫번째로 등록한 공연장의 구역에 총 좌석 개수보다 경매 좌석이 큰지 작은지 검도해야했고, 그다음으로 그전에 저장한 경매 좌석이 중복체크를 진행해야했다. 여기까지 검증하는건 사실 큰 문제는 아니였지만 http, js.. 이전 1 2 3 4 5 6 ··· 13 다음
