요번엔 책을 잘못 골랐다…

• 문제를 증상의 관점, 즉 사용자가 바라보는 관점으로 관찰해야 한다
• 증상이 처음 발현된 곳으로 가서 확인해 보자
• 텔레메트리 측정에서 기능의 종류, 시작 시각, 완료 시각, 사용자, 사용량 측정은 필수이다
• 비즈니스 측면에서 증상을 분류하고 최우선 순위부터 해결하자 → 쉬운것부터 하지 마라
• 재현 테스트 케이스는 문제 재현 방법, 기대했던 동작, 실제 동작을 기록해야 한다
• 정상적인 실행 데이터도 기록해야 한다
  • 기준 데이터와 비교하여 가설을 세워야 하는 부담이 크게 줄어든다
  • 확장성 문제에 대해 미리 예측 할 수 있다
• 오래 걸리는 프로그램에서 원래 작동 시간의 3배 이상을 추적해야 할 필요는 거의 없다
  • 기존 프로파일과 비교하여 쉽게 원인을 찾을 수 있다
  • 속도를 느리게 만드는 몇 가지 이벤트만 파악해도 개선이 충분히 가능하다
• 추적 비용은 +5% 정도가 대게 적당하다 → 사용자들이 변화를 쉽게 눈치 챌 수 없다
• 필터링은 가장 이른 시점에 하는 것이 좋다 → 항상 성능 최적화 시에 염두해두자
• 해결책의 범위는 증상의 범위와 비례하도록 유지하자
  • 다른 리소스에 영향을 주는 것을 최소화해야 한다
  • 로컬 파라미터를 우선으로 하고 전역 파라미터를 최대한 변경하지 않도록 하자
• 병렬 작업은 응답 시간을 줄일 수는 있으나 부하가 줄어들지는 않는다 → 오히려 늘 수도 있다
• 인간은 멀티태스킹이 매우 비효율적이다…
• 비율 하나만 보고 의사 결정을 내리지 말자 → 분자, 분모에 따라 얼마든지 왜곡이 가능하다
• 피드백 루프는 가능한 짧게 가져가자 → 빠른 실패에 도움이 된다
• 간단한 문장으로 설명할 수 없다면 이해한 것이 아니다
• 토우-밀샙 법칙: 쿼리 결과의 10개 이상의 행을 보고 싶어하는 사용자는 없다는 관찰 결과