실행 중인 시스템의 성능을 이해하는 법을 배우는 것은 디버깅을 배우는 이유와 것과 같은 이유로 피할 수 없는 일입니다. 여러분이 작성하는 코드의 비용을 완벽하고 정확하게 이해하고 있더라도 그 코드에서는 여러분이 통제하거나 속을 들여다보기가 힘든 다른 소프트웨어 시스템을 호출하게 될 것입니다. 하지만 실무에서 성능 문제는 일반적으로 디버깅과 조금 다르고 조금 더 쉽습니다.
시스템이나 하위 시스템이 너무 느리다고 고객이 느낀다고 가정해 봅시다. 그것들을 좀 더 빠르게 만들려고 하기에 앞서 왜 그것이 느린가에 대한 멘탈 모델을 만들어야 합니다. 이를 위해 프로파일링 도구나 로그를 이용해 어느 부분에서 시간이나 다른 리소스가 실제로 소비되는지 파악할 수 있습니다. 코드의 10%에서 90%의 시간이 소모된다는 격언이 있습니다. 저는 이와 더불어 성능 문제에 대한 입출력 비용(I/O)의 중요성을 더하고 싶습니다. 대부분의 시간이 대체로 I/O에서 소모되는 경우가 많습니다. 비용이 높은 I/O와 코드 중에서 높은 비용이 드는 10%를 찾는 것이 멘탈 모델을 만들기 위한 첫 번째 단계입니다.
컴퓨터 시스템의 성능에는 여러 차원이 있으며, 그리고 많은 자원들이 소비됩니다. 맨 먼저 측정해야 할 리소스는 벽시계 시간(wall-clock time), 즉 계산을 하는 동안 경과된 총 시간입니다. 벽시계 시간(wall-clock time)을 로깅하는 것은 특히 중요한데, 시뮬레이션에서 발생하는 예상 불가능한 상황에 관해 알려줄 수 있기 때문이며, 이는 다른 프로파일링에서는 불가능한 것입니다. 하지만 그렇다고 해서 이것이 항상 전체 그림을 보여주는 것은 아닙니다. 간혹 시간은 조금 더 걸리지만 너무나도 많은 프로세서 시간을 소모하지는 않는 뭔가가 실제로 여러분이 다뤄야 할 컴퓨팅 환경에서는 더 나을 것입니다. 이와 비슷하게, 메모리, 네트워크 대역폭, 데이터베이스나 기타 서버 접근은 결국 프로세서 시간보다 훨씬 더 비용이 높을 수 있습니다.
동기화된 공유 자원에 대한 경합은 교착상태(deadlock)와 기아상태(starvation)를 유발할 수 있습니다. 교착상태는 부적절한 동기화나 자원 요구 때문에 진행할 수 없는 것을 말합니다. 기아상태는 어떤 컴포넌트를 적절히 스케줄링하는 데 실패하는 것입니다. 어쨌거나 이를 예상할 수 있다면 프로젝트 초기부터 이러한 경합을 측정하는 수단을 마련하는 것이 가장 좋습니다. 이러한 경합이 일어나지 않더라도 자신 있게 이를 단정(assert)할 수 있는 것이 아주 도움될 것입니다.
- 다음 항목: 성능 문제를 고치는 법
