3. load test (진짜인가..)

1. 동시접속자 loop count : 100

1. 100명의 사용자, duration 10, arrivalRate : 10

2. 300명의 사용자, duration 30, arrivalRate : 10

3. 600명의 사용자, duration 60, arrivalRate : 10

4. 600명의 사용자, duration 60, arrivalRate : 10

목업데이터에는 100명의 인원을 넣어둠. 목업데이터에 10명만 넣었을대랑 뭔가 다른가하고 실시.
=> 뭐가 다른지 모르겠음;

devtools에 들어가서 performance 보려고햣는데 인터넷창이 꺼져버렷다. 오마이갓!

5. 1000명의 사용자 duration 10, arrivalRate : 100

serialziable을 쓴 결과

---

---

👊💥 serialziable을 사용한 상태로 성능 개선을 해보자.

1) 인덱싱을 이용

인덱싱(indexing): 주로 검색 및 조회를 할때 큰 효율성
데이터베이스에 색인을 남기는 것. 색인을 통해서 검색의 범위를 줄이는 것이 조회에 있어 훨씬 효과적.

• 조건을 만족하는 튜플들을 빠르게 조회하기 위해
• 빠르게 정렬(orderby)하거나 그룹핑(groupby)하기 위해

예매에서 인덱싱을 적용하기에는 좀 무리가 있어보여서 공연 예매 조회 api에서 우선 실험하기로 해본다.

-- Reservation 테이블의 userId 중복허용 인덱스걸기
CREATE INDEX userId ON Reservation(userId);
-- Reservation 테이블의 showId 중복허용 인덱스걸기
CREATE INDEX showId ON Reservation(showId);

config:
  environments:
    local:
      target: 'http://localhost:3334'
      phases:
        - duration: 10
          arrivalRate: 10
          name: Warm up
      defaults:
        User-Agent: 'Artillery'
      payload:
        - path: 'users.csv'
          fields:
            - 'username'
            - 'password'
        - path: 'usersToken.csv'
          fields:
            - 'userToken'
scenarios:
  - name: '공연 예매 조회'
    # - name: '공연 목록 조회 - 상세조회 - 예매(1000명)'
    flow:
      # 공연 예매 내역 조회
      - get:
          url: '/api/reservation/detail/user'
          headers:
            authorization: '{{userToken}}'

우선 duration 10, arriavalRate 10으로 테스트해봤다.상태코드 400으로 뜨는건 예약이 없는 사용자가 있기 때문.

reservation의 테이블에 있는 외래키들만 인덱스를 주면 될거라고 생각했는데 확인해보니까 이미 인덱스가 걸려있었다. 알고보니 기본키(primary key), 외래키(foreign key)는 기본적으로 인덱스가 걸려있다고 한다.

쿼리에서는 전부 기본키, 외래키를 이용해서 find, update를 했기때문에 굳이 인덱싱을 안해줘도 될듯하다.

=> 인덱싱 방법 포기! (추후 쿼리문이 수정된다면 다시 돌아올 수 있음)

2) 캐싱을 이용 - Redis 인메모리방식