Performance Test

작성된 쿼리가 얼머나 효율적이고 확인하기 위해선 먼저 실행 계획을 검토 뿐만 아니라, 실제 쿼리를 실행하여 성능을 직접 측정하는 과정이 필수적이다.

쿼리 성능 영향 요소

정확한 성능을 측정하기 위해서는 테스트 결과에 영향을 미칠 수 있는 여러 환경적 요소를 인지하거나 통제해야한다.

1. 운영체제 캐시

MySQL 서버는 운영체제의 파일 시스템 관련 기능(시스템 콜)을 통해 데이터 파일을 읽어오게 되고, 운영체제에서 한 번 읽은 데이터는 운영체제가 관리하는 캐시에 저장한다.

• InnoDB: 파일 시스템의 캐시나 버퍼를 거치지 않는 Direct I/O를 사용 -> 상대적으로 영향 적음
• MyISAM: 운영체제 캐시 의존도 큼 -> 영향 큼

InnoDB 스토리지 엔진에서는 영향이 적지만, 더 정확한 성능 테스트를 위해선 별도의 운영체제 캐시 삭제 명령어를 실행하고 테스트를 진행해볼 수 있다.

2. MySQL 서버 버퍼 풀

운영체제의 버퍼나 캐시와 마찬가지로 MySQL 서버에서도 데이터 파일의 내용을 페이지 단위로 캐시하는 기능을 제공한다.

• InnoDB 버퍼 풀: 인덱스 페이지 + 데이터 페이지까지 캐시하며, 쓰기 지연 작업을 위한 버퍼링 작업까지 수행
• MyISAM 키 캐시: 인덱스 페이지만 캐시

이러한 내부 캐시들은 성능 테스트에 영향을 미칠 수 있기 때문에, MySQL 서버를 재시작하여 캐시를 초기화한 후 테스트를 진행해 볼 수 있다.

3. 독립된 MySQL 서버

정확한 성능 테스트를 하기 위해선 웹 서버나 다른 배치용 프로그램이 실행되고 있다면 영향을 받을 수 있기 때문에, 독립된 MySQL 서버를 사용하는 것이 좋다.

테스트 방법

쿼리 성능은 서버의 캐시 상태에 따라 크게 달라진다.

• 워밍업 상태: 서버가 막 재시작되었거나 관련 데이터가 캐시에 전혀 없는 상태
  • 쿼리 실행 시 모든 데이터를 디스크에서 읽어와야 하므로 응답 시간이 가장 오래 걸리는 최악의 시나리오
• 콜드 상태: 쿼리 실행에 필요한 데이터와 인덱스가 이미 InnoDB 버퍼 풀과 같은 캐시에 준비되어 있는 상태
  • 실제 운영 환경의 데이터베이스는 대부분 콜드 상태에 가까움

실제로도 서비스 환경의 쿼리는 워밍업 상태에서 실행되기 때문에 워밍업 상태에서 다음과 같이 테스트하는 것이 좋다.

테스트 절차

1. 측정하고자 하는 쿼리를 연속으로 6 - 7회 이상 실행한다.
2. 최초 1 - 2회의 실행 결과는 측정치에서 제외
   • 운영체제 캐시나 MySQL 버퍼 풀 및 키 캐시가 준비되지 않은 상태이기 때문에, 디스크 I/O가 집중되어 비정상적으로 느리게 측정되기 때문
3. 안정화된 나머지 실행 결과들의 평균값을 최종 성능 측정치로 삼음

결과 해석

성능 테스트를 통해 얻은 실행 시간 등은 절대적인 수치가 아닌, 상대적인 비교 지표로 활용해야 한다.

• 테스트 환경과 실제 운영 환경은 하드웨어, 데이터 분포, 동시 부하 등 여러 요소가 다르기 때문
• 성능 테스트의 주된 목적은 정확히 n ms 걸린다를 예측하는 것이 아니라, 두 개 이상의 쿼리 중 어느 쿼리가 더 효율적인지를 판단하는 것

참고자료

• Real MySQL 8.0 (2권)