Performance Test(성능 테스트)
작성된 쿼리가 얼머나 효율적이고 확인하기 위해선 먼저 실행 계획을 살펴보고 검토하게 된다. 거기에 특별히 문제될 부분이 없다면 직접 실행해보고 성능을 측정해보는 것이 좋다. 하지만 여기서 테스트 할 때 방해 요소가 있기 때문에 이 부분들을 고려해야하고, 어떤 영향 요소가 끼치는 것이 있는지 아는 것이 중요하다.
쿼리 성능 영향 요소
쿼리 성능에 영향을 끼치는 가장 큰 변수는 MySQL 서버가 가지고 있는 여러 종류의 버퍼나 캐시가 있으며 자세한 목록은 아래와 같다.
1. 운영체제 캐시
MySQL 서버는 운영체제의 파일 시스템 관련 기능(시스템 콜)을 통해 데이터 파일을 읽언오는데, 이 때 운영체제는 한 번 읽은 데이터는 운영체젝 관리하는 캐시에 저장한다. InnoDB 스토리지 엔진은 파일 시스템의 캐시나 버퍼를 거치지 않는 Direct I/O를 사용하여 큰 영향을 미치지 않지만, MyISAM 스토리지 엔진은 운영체제 캐시 의존도가 크기 때문에 영향을 많이 받는다.
운영체제가 관리하는 캐시나 버퍼는 공용 공간이기 때문에 MySQL 서버가 종료되어도 여전히 남아있을 수 있기 때문에, 운영체제 캐시/버퍼가 없는 상태에서 테스트를 하기 위해 별도의 운영체제 캐시 삭제 명령어를 실행하고 테스트를 진행하는 것이 좋다.
2. MySQL 서버 버퍼 풀(InnoDB 버퍼 풀과 MyISAM의 키 캐시)
운영체제의 버퍼나 캐시와 마찬가지로 MySQL 서버에서도 데이터 파일의 내용을 페이지 단위로 캐시하는 기능을 제공한다.(InnoDB - 버퍼 풀, MyISAM - 키 캐시)
InnoDB 버퍼 풀은 인덱스 페이지 + 데이터 페이지까지 캐시하며, 쓰기 작업을 위한 버퍼링 작업까지 수행하며, MyISAM은 인덱스 데이터에 대해서만 캐시한다.
버퍼 풀과 캐시는 MySQL 서버가 시작되면 캐싱된 내용을 강제로 삭제할 수 있는 방법이 없으며, 그러기 위해서는 MySQL 서버를 재시작해는 방법밖에 없다.
(이마저도 InnoDB 버퍼 풀은 종료될 때 자동으로 덤프되기 때문에, innodb_buffer_pool_load_at_startup 옵션을 off로 설정해야 삭제된다.)
3. 독립된 MySQL 서버
정확한 성능 테스트를 하기 위해선 웹 서버나 다른 배치용 프로그램이 실행되고 있다면 영향을 받을 수 있기 때문에, 독립된 MySQL 서버를 사용하는 것이 좋다.
4. 쿼리 테스트 횟수
실제 쿼리 성능 테스트를 MySQL 서버의 상태가 워밍업 된 상태 혹은 콜드 상태에서 진행할지 고려해야한다.
워밍업 상태: 캐시나 버퍼가 필요한 데이터로 준비된 상태
콜드 상태: 캐시나 버퍼가 모두 초기화된 상태
일반적으로 쿼리의 성능 테스트는 워밍업 상태를 가정하고 테스트하는 편이며, 실제로도 서비스 환경의 쿼리는 워밍업 상태에서 실행되기 때문에 워밍업 상태에서 테스트하는 것이 좋다.
운영체제의 캐시나 MySQL의 버퍼 풀/키 캐시는 크기가 제한적이기 때문에 쿼리에서 필요로 하는 데이터나 인덱스 페이지보다 작으면 플러시 작업과 캐시 작업이 반복해서 발생한다.
때문에 한 번의 쿼리 테스트로는 정확한 성능을 측정하기 어렵고, 테스트할 쿼리를 번갈아 가며 67번 실행한 뒤 최초 12번의 실행 결과는 제외하고 평균값을 측정하는 것이 좋다. (최초 1~2번의 실행 결과는 운영체제 캐시나 MySQL 버퍼 풀 및 키 캐시가 준비되지 않은 상태이기 때문에, 많은 시간이 소요되는 편이라 편차가 크기 때문이다.)
하지만 결국엔 쿼리 성능을 비교하는 것은 상대적인 비교이며, 절대적인 성능은 아니다. 실제 서비스 중인 환경에는 다른 요소들이 많기 때문에 쿼리 성능 테스트 결과를 그대로 따르고 적용하는 것은 위험하다.
참고자료
Last updated