최근 티스토리를 비롯한 태터툴즈의 속도 향상 작업을 하면서 새삼 깨닫게 되는 법칙이 "측정 효과"일 것이다.

정확히 기억은 나지 않지만 어떤 Software Engineering 책에서 읽은 예제인데 어떤 공장에서 조도에 따른 작업 효율을 측정하는 예제가 기억난다. 기본 상태에서 공장 노동자들의 생산성을 측정한 후 조도를 높여 보았더니 생산성이 증가하는 것으로 측정되었다. 그래서 이번엔 조도를 처음보다 낮추어 보았더니 역시 증가된다는 것이다. 조도 뿐만이 아니라 측정 그 자체가 실험의 환경변수가 되어 버린다.

프로그램 혹은 어플리케이션의 속도를 향상시키는 작업에서 기본적으로 하는 활동 중 하나가 Profiling 즉 현재 상태에 대한 측정일 것이다. 운좋게 딱 한군데의 버틀넥(Bottle-Neck)을 찾아 낼 수도 있겠지만 일반적으론 각 모듈의 수행 시간이나 메모리 사용량, I/O 회수, Lock에 의한 Pending 등의 데이터가 뽑아져 나오고 이것이 개발자의 책상 위에 뿌려진다. 이후 작업은 이 데이터에 기반하여 가설을 세우고 이리 저리 실험(Trial)을 하다가 운좋게-정말 뒷걸음질 치다가- 성능이 XX% 향상 되거나 아니면 "성능 향상을 위한 시스템 증설 기획안"을 작성하기 시작할 것이다.

아무튼 이 Profiling 과정의 가장 무서운 점은 시간 측정 코드를 코드에 적용되는 순간부터 실제 상황이랑 간격이 벌어진다. 항상 현재 시각을 물어보느라 시피유를 괴롭히고 한 인스트럭션과 다음 인스트럭션 사이에 항상 간격이 생기면서 락문제가 해결되기도 혹은 엉뚱한 곳에 생기기도 한다. 더우기 msec 단위로 튜닝을 하는 상황에서라면 현대의 똑똑한(?) CPU나 OS, VM(혹은 그 외 블라블라들)의 가속을 적용받지 못하거나 하면서 화성 위치에 촛점을 맞추고 목성의 사진을 찍는 상황이라고 할까.

이번에 작업하면서 가장 힘들었던 부분이라고 하면 이 PHP라는 언어를 사용하는 환경에서는 제대로 된 프로파일링 조차 힘들다는 것이다. 이전의 VC++환경에서 작업할 때는 Intel의 VTune이라는 초강력 툴이 있어서 그나마 데이터 뽑기가 수월했는데 현재 제공되는 온갖 프로그램들로 난리를 쳐 봤으나 만족할만한 데이터가 나오지 않았다. 원래 이 작업이 끝나면 각 툴들에 대한 리뷰를 해 보고 싶었으나 아직 그정도의 완성도는 아니라고 보인다. 검색엔진에서 찾아본 수많은 사람들의 나름대로 분석 방법도 원래 웹 어플리케이션이 도는 상황과 너무나 달랐다.


PS.
이번의 속도 향상에 관련된 변경사항이 일부 태터쪽에도 반영이 들어갔습니다. 아마 보신분은 뭐 별로 바뀐 것도 없네라고 하시겠지만 첫페이지 속도가 꽤 빨라졌습니다. 완전 로또에 당첨된 상황입니다. 이런 운이 다시 저에게 찾아올지는... :)

'개발&Development > 프로그래밍 일반' 카테고리의 다른 글

수요와 공급  (2) 2006.10.23
코더의 길  (1) 2006.09.01
어플리케이션 속도 튜닝 노가다  (0) 2006.08.09
주석은 쓸모없는 것 2  (0) 2006.07.24
GC's problem of JavaScript  (0) 2006.07.18
가비지 컬렉팅, Loosely type binding, 기타 등등  (2) 2006.07.08