パフォーマンス分析に関するアンチパターン

いくつかの書籍に書かれたパフォーマンス分析に関するアンチパターンを整理してみた。ここに無いものでご存知のパターンがあればご教授いただきたい。アーキテクチャや組織のパターンはよく見るけど、対応手法に関するパターンってあんまり多くないのかも（もしくは単にアンテナ感度が悪いだけ？）

詳解 システム・パフォーマンス (Systems Performance: Enterprise and the Cloud)より

詳解 システム・パフォーマンス

第2章 メソドロジでいくつかアンチパターンが紹介されている(アンチではないほうのパターンも)。
書籍の内容の一部は、以下の翻訳記事および元ネタ記事と同様と思われるので、書籍にあたる前に一読するのが良いかも。

• パフォーマンス分析の方法論23選 | POSTD

Streetlight Anti-Method (街灯のアンチメソッド)

自分のよく知っている観察ツールや、インターネットで拾ってきた可観測性ツール、その他何でも適当な観察ツールを使って、何か明らかな問題が現れるかどうかをチェックしてパフォーマンス分析とする

このメソドロジは、次のたとえ話が示す街灯効果（streetlight effect）という観察結果のバイアスから命名されている。

ある晩、警察官は街灯の下で探しものをしている酔っぱらいを見て、何を探しているのかと尋ねる。酔っぱらいは鍵を失くしたという。警察官も見つけられず、酔っぱらいに尋ねる。「街灯の下のここで失くしたというのは確かなことなんですか？」 酔っぱらいは答える。「いいや、でもここは明かりの具合が一番いいからね」

詳解 システム・パフォーマンス

Random Change Anti-Method(ランダム変更アンチメソッド)

どこに問題があるかを適当に推測し、その問題が消えるまで適当に変更を加える。

Blame-Someone-Else Anti-Method(誰か他人のせいにするアンチメソッド)

1. 自分に責任のないシステムまたは環境のコンポーネントを見つけてくる。
2. そのコンポーネントに問題があるという仮説を立てる。
3. そのコンポーネントに対して責任を負うチームに問題を丸投げする。
4. 仮説の誤りが証明されたら、ステップ1 に戻る。

詳解 システム・パフォーマンス

Optimizing Java

Optimizing Java: Practical Techniques for Improving JVM Application Performance (English Edition)

Chapter 4. Performance Testing Patterns and Antipatternsでいろいろと紹介されている。

Distracted by Shiny

レガシーコードは掘り起こさず、新しい技術やテクノロジー部分からチューニングしようとする

Distracted by Simple

われわれが理解している部分から始めよう

Performance Tuning Wizard

天才、スーパーヒーローを雇用して対応する

Tuning by Folklore(民間伝承に基づくチューニング)

「マジック」設定パラメータをネットで探すことに熱中する

The Blame Donkey

分析せずに、特定のコンポーネントが原因だと決め付ける

Missing the Bigger Picture

全体像を把握する前に、アプリケーションの特定の部分のプロファイリングや変更に注力する

UAT Is My Desktop

本番環境と異なる環境で調査する

Production-Like Data Is Hard

本番環境と同等のデータを準備することは難しい

個人的なまとめ

結局のところ、環境やOSを含めたアーキテクチャの全体像をモデル化して計測を行い、仮説の構築と測定を繰り返すのが正しいと思われる。しかし全体像のモデル化が難しい。Linuxサーバであれば「詳解 システム・パフォーマンス」を参考にするのが良さそう。Winodwsサーバはどうだろう、手元で取り扱っていないので良いモデルがあるのかはちょっとわからない。

おまけ：開発者が間違った技術選択をし続ける理由

前述の「Optimizing Java」で紹介されていたブログポストが興味深いのでこちらもピックアップしておく

• Why Developers Keep Making Bad Technology Choices | Carfey Software Blog

• 理由#1：退屈
• 理由#2：開発者の経歴書に追加するため (Résumé Padding)
• 理由#3：同僚や上司からの圧力
• 理由#4：技術理解の欠如
• 理由#5：誤解／存在しない問題に対する対処

どれも困ったことだけど、気持ちはよくわかる。#1～#3が発生しないように気をつけたいけれども、どうしたものか。

おまけ：アンチパターンのたのしみ

主人公たちの失敗をオーバーに描くことは、喜劇の定石である。その意味で本書の読後感ならぬ読中感は、アメリカ製の上出来の喜劇映画を見ている思いがする。なにしろ、この本は一貫して笑える。
アンチパターン―ソフトウェア危篤患者の救出 訳者あとがき、より

アンチパターン―ソフトウェア危篤患者の救出