p.4
어떤 도구의 결과를 해석하기 위해 많은 설명이 필요하다면 도구를 잘못 설계한 것이다.
p.14
만약 대상 환경의 데이터 경로를 보여주는 도식이 없다면 찾아보거나 직접 그리자. 그 그림은 각 구성 요소 간의 관계를 이해하고 전체 영역에서 간과하는 부분이 없게끔 도와줄 것이다.
p.16
각 개발 단계를 거칠 때마다 앞 단계에서 내린 아키텍처 결정으로 인해 성능 문제를 수정하는 것은 점차 더 어려워진다.
p.17
자원 사용을 감시하는 이유는 문제가 발생하기 전에 가능한 한 이를 예측하기 위해서다.
p.18
어떤 지표가 "좋은" 것인지 "나쁜" 것인지는 어느 정도 애플리케이션 개발자나 실 사용자의 성능 기대치에 달려 있다. 주관성은 명확한 목표를 설정하는 방식으로 객관화할 수 있다.
p.19
성능상 문제가 있다는 것을 알아내는 것이 아니라 가장 문제가 되는 것(들)이 어떤 것인지 알아내는 것이 성능 분석 시 해야 할 일이다.
성능 분석가는 각 문제의 규모를 정량화할 수 있어야 한다. 이상적인 경우라면 각 문제를 정량화할 뿐 아니라 각각을 해결하면 얼마나 속도 향상을 가져올 수 있는 지도 추산해야 한다. 이런 정보는 의사 결정권자들이 엔지니어링이나 운영 자원을 사용할 수 있도록 정당화해야 할 때 가치가 있다.
p.21
커널 내부를 분석하는 것은 캄캄한 방을 커널 엔지니어가 미리 예상해서 박아 둔 촛불(시스템 통계)을 사용해 탐험하는 것과 같다. 반면 동적 트레이싱은 아무데나 비출 수 있는 손전등 불빛과 같다.
p.29
성능이 좋지 않은 복잡한 시스템 환경에 마주칠 때, 첫 번째 모험은 바로 어디서 분석을 시작하고, 어떤 데이터를 모으며, 그 데이터를 어떻게 분석하느냐 하는 문제일 수 있다.
p.37
어떤 환경의 성능 특성은 사용자 추가, 새 하드웨어 설치, 소프트웨어나 펌웨어의 갱신이 일어나기 때문에 시간에 따라 변한다.
댓글