[자성튜이] 반드시 튜닝해야 하는 대상

대상 찾기

• 상위 20%의 화면을 분석 및 튜닝 대상으로 선정
• 기존 시스템 모니터링 툴의 통계 기능을 사용하여 찾기
• 기존 시스템의 웹 로그를 분석하기

 

예시

구분	화면명
초기 화면	로그인
원무	환자 접수 신청
진료	환자조회 처방전 지정 치료 일수 입력 처방 내림 외래 기록지 저장
원무	수납 조회 수납 처리

• CASE1
  • 안내원은 환자의 이름을 '김'으로만 조회했다
  • 그런데 시스템의 응답이 없어서 안내원은 계속 검색 버튼을 누르기 시작했다
  • 안내원이 검색을 누른 후부터 해당 애플리케이션이 DB의 CPU 대부분을 점유했고
  • DB쿼리의 문제로 오픈이 연기되었다
• CASE2
  • 한 시스템이 매일 14~16시 사이에만 다운되는 현상이 있어 진단
  • 이 시스템은 내부용 시스템이 아니라 대외로 오픈된 시스템임
  • 시스템의 로그 분석을 해서 하나의 화면이 한 시간에 10만 번 이상 호출되는 것을 발견
  • 문제가 된 화면은 천 개가 넘는 관련 협력사의 요청 처리 정보가 그 시간대에 공개되는 화면
  • 기존 서버 구성은 두 대의 서버가 있고 각 서버에 있는 인스턴스 3개가 서로 클러스터링이 되어 있었음
  • 현 시스템의 인스턴스 중 각 서버당 하나의 인스턴스에서는 문제 되는 화면만 수행하고, 나머지 인스턴스에서는 나머지 모든 화면을 수행하도록 수정

 

• CASE2 -1
  • 화면을 진단한 결과
  • 호출되는 화면의 응답 속도는 0.2~0.3초로 양호
  • 검색 시 DB 쿼리 수행 시간 대 애플리케이션 수행 시간의 비율은 8:2로, DB에서 많은 응답 시간이 소요됌
  • 검색 조건 화면을 로딩할 때 DB에서 3회 검색을 수행
  • 실제 응답 속도는 0.2~0.3초가 소요되지만, 화면의 응답 속도는 사용자가 증가할수록 증가하는 현상이 발생
  • DB 쿼리 수행 시간 및 애플리케이션 수행 시간이 증가하면서 발생하는 당연한 현상임
  • 이 화면에서 실행되는 쿼리는 화면 1회를 수행할 때마다 총 49번
  • 데이터를 가져오기 위한 쿼리도 있었지만, 코드성 데이터를 가져오기 위한 쿼리도 다수 존재하였음
  • 메모리에 코드성 데이터를 올려서 사용하게 처리

 

• CASE2 -2
  • 또 하나의 문제는 검색 조건 화면을 로딩할 때 DB쿼리를 수행한다는 것
  • 시스템의 표준 때문에 이러한 현상이 발생한다는 것을 발견
  • 해당 시스템은 정확한 시스템의 시간을 가져오기 위해서 DB의 시간을 쿼리해 오도록 되어 있었음
  • 하지만 그 검색 조건 화면은 시간까지는 필요하지 않았음
  • 년, 월, 일만 필요하고, DB에서 정확한 시간을 가져올 필요까지는 없는 검색 조건이었음
  • 그래서 이 부분은 WAS 시스템 시간을 가져오는 것으로 변경