공부22 728x90 [ParkNav] 예약처리 일관성 테스트 Case 1, Case 2 : 주차시간을 지켜 주차한 경우로, 보편적이고 일반적인 상황이라 가정한다. Case 3, Case 4 : 주차시간을 지키지 않은 경우로, 예외 상황이라 가정한다.→ 예외상황에서 version 1 , version 1-1 은 예약차량 입차가 가능한 상황에서 version 2 는 입차 안정성을 갖지 못하는 경우도 발생한다. → 일반적인 상황, 예외상황 모두 포함하여 version 2 가 예약차량 입차 안정성과 주차장 운영 효율성 모두 가장 높은 수치를 갖는다. 예약처리 일관성 테스트 상황 설정 주차장 총 구획 수 : 5자리 11:00 이후 주차장에 차량이 없으므로, 14:0015:00, 15:0016:00 예약시 성공해야 한다. 테스트 결과 version 0 의 경우, 1번•3번은.. 2023. 4. 27. [ParkNav] 알고리즘 Version 0 ~ Version 2 Version 0 예약 예약시작시간이 종료시간보다 늦게 입력된 경우 예외처리 NOT_END_TO_START(400,"입차시간이 출차시간보다 빨라야 합니다.") 주차장 ID가 주차장 정보 DB에 없는 경우 예외처리 NOT_FOUND_PARK(400, "등록된 주차장이 없습니다.") 로그인한 유저의 대표차량이 등록되지 않은 경우 예외처리 NOT_FOUND_CAR(400, "등록된 차량이 없습니다.") 예약시작~종료시간 사이에 동일차량으로 예약한 내역이 있는 경우 예외처리 ALREADY_RESERVED(400, "이미 예약된 시간입니다.") 주차장 운영정보가 없는 경우 예외처리 NOT_FOUND_PARK_OPER_INFO(400, "해당 주차장 운영정보가 없습니다.") 현재 주차가능 대수와 선택시간 예약건수 .. 2023. 4. 27. [ParkNav] QueryDSL을 이용한 성능개선 문제점 기존 관리자 페이지를 호출 시 페이지를 호출하는 시간이 너무 오래걸리는 문제가 발생했고 페이지 호출 시간 = 데이터의 개수 만큼의 페이지 지연이 발생되었다. 군산오름 주차장 기준 1461ms 가 소요되었다. 원인 기존 로직의 흐름에 문제가있었는데 다른 두 테이블의 데이터를 합쳐야 하고 검색조건에 맞는 결과만 내어줘야하기 때문에 두번의 DB호출에서 Pageable을 걸지 못했고 얻어온 데이터를 합치는 과정에서 검색조건을 필터링 했는데 그 결과 많은 쿼리 조회로 인해 페이지 조회가 느려진것이다. 기존 로직은 다음과 같다. 주차장의 모든 예약정보를 가져온다. 예약 정보 중 입차 한 기록이 있는지 DB에서 검색한다. 입차 했을경우 : 검색 조건에 맞는 데이터를 입차 차량으로 리스트에 추가한다. 입차 안했.. 2023. 4. 19. [ParkNav] 검색 성능 개선 기록 성능 개선 결과 최초검색 : 13724 ms 조회로직 변경 : 7847ms Fetch Join 변경 : 319ms 조회 쿼리 변경 : 256ms 기본 검색 기능 기본적인 주차장 검색기능을 구현했다. 검색어로 검색 카카오맵 API로 사용자 검색어에 대한 결과를 호출 검색 결과가 있는경우 : 검색결과 0번으로 좌표를 반환 검색 결과가 없는경우 : 초기위치 ( 서울역 ) 반환 좌표 주변의 주차장 검색 검색 결과가 있는경우 : 검색 결과를 반환 검색 결과가 없는경우 : 초기위치 ( 서울역 ) 반환 현위치로 검색 현위치 정보 동의 여부 동의 : 현위치 좌표 주변 DB검색 비동의 : 검색실패 위치동의 알림 창 출력 검색결과가 있는지 여부 검색 결과가 있는 경우 : 주변 주차장 리스트 반환 검색 결과가 없는 경우 :.. 2023. 4. 19. 이전 1 2 3 4 5 6 다음
