1 그룹웨어 전자결제 모듈의 문제

2 성능 튜닝

옛날에 근무하는 회사에 그룹웨어의 전자결제는 매우 느렸었다. 외부에서 솔루션을 도입하였으나 자체적으로 커스터마이징이 엄청나게 된 상태라 솔루션을 판매한 회사에서도 건드리지 못하는 상황이었다. 전자결제로 월말/월초에 처리는 업무가 많은 직원은 클릭 한 번으로 몇 십초씩 기다려야 하거나 심지어는 'Request Timeout' 이라는 메시지를 볼 때도 있었다. 분석 결과 겉으로 드러나 보이는 문제는 저장 프로시저 내에서 과도한 사용자 정의 함수 호출에 있었다. DBMS는 SQL Server 2000으로 사용자 정의 함수에 쥐약인 제품도 한 몫 단단히 하고 있었다. 우리의 개발자는 열심히 함수를 주무르고 있었다. 그러나 문제의 원인은 따로 있었다. 바로 가장 단순하 문제인 '속성의 원자값' 문제였다. 여러 컬럼에서 '결제선'이 '{부서,직급,성명} -> {부서,직급,성명} -> {부서,직급,성명} ...'은 형태였다. 컬럼도 한 두개가 아니였다. 결제 문서를 업데이트 하려고 하면 또한 엄청난 부하를 줘야 했다. 다음과 같은 구조였다.

사용자의 상황은 다음과 같다.

• 일반 사원
  
  • 1~7초 (서버의 자원 사용 상태에 따라 틀림)
    
• 전자결제 항목이 많은 사원
  
  • 10초 이상
    
  • 심한 경우 Request Time Out 발생
    
    

필자는 개발자에게 성능 저하의 근본 원인이 어플리케이션이 아닌 설계에 있음을 설명하였고, 전자 결제에 대한 새로운 모델을 제안하였다. 다행히도 개발자는 흔쾌히 제안을 받아들이고 작업에 착수하였다. 그리하여 전자결제의 모델은 다음과 같이 변경되었다.

작업이 진행되고 얼마 지나지 않아 개발자는 쿼리가 0.8초가 나온다면서 '아~ 0.8초~! 재학씨 가슴이 아퍼요~' 라고 안타까워하고 있었다. 그 전에는 5초가 나와도 그러려니 하던 사람이 말이다. 개발자의 지대한 관심을 받은 전자결제 모듈은 Profiler로 모니터링 결과 일반사원이나 전자결제 항목이 많은 사원 모두 대부분 0.06초 이내에 처리되었고, 최대 0.1초 내에 처리되는 것을 볼 수 있었다. 우리에 개발자는 이쁜 여사원에게 고맙다는 상큼한 말을 들을 수 있었다.