プログラマは、API パフォーマンスに対する期待に基づいて、API、データ構造、および全体的なプログラム構造を選択します。期待やパフォーマンスが大きく間違っている場合、プログラマは API 呼び出しを調整するだけでは回復できず、プログラム (おそらく主要な部分) を書き直す必要があります。前述した対話型プログラムの防御構造も一例です。
もちろん、その構造やパフォーマンスがライブラリのパフォーマンスにほとんど影響されないプログラムも数多くあります (科学技術コンピューティングや大規模なシミュレーションがこのカテゴリに分類されることがよくあります)。しかし、今日の「通常の IT」の多く、特に Web ベースのサービス全体のソフトウェアでは、全体的なパフォーマンスに重要なライブラリが広範囲に使用されています。
特にさまざまなメディアを扱うプログラムでは、パフォーマンスの小さな変化でも、プログラムに対するユーザーの認識に大きな変化を引き起こす可能性があります。ビデオ ストリームの時折のフレーム落ちは許容できる場合がありますが、ユーザーは音声のわずかな中断さえも知覚できるため、音声メディアのパフォーマンスの小さな変化がプログラム全体の許容性に重大な影響を与える可能性があります。この懸念により、さまざまな意味で高レベルのパフォーマンスを確保することを意味するサービスの品質に対する大きな関心が高まっています。
パフォーマンス契約の違反はまれで、致命的な事態になることはほとんどありませんが、ソフトウェア ライブラリを使用するときにパフォーマンスに注意を払うと、より堅牢なソフトウェアを構築することができます。以下にいくつかの経験的原則を示します。
1 APIとプログラム構造を慎重に選択する
幸運にもプログラムを最初から作成できる場合は、プログラムの作成を開始するときにパフォーマンス契約の影響について考えてください。プログラムがプロトタイプとして開始され、その後しばらく運用される場合、少なくとも 1 回は間違いなく書き直されることになります。書き換えは、API とアーキテクチャの選択を再考する機会となります。
2 新しいバージョンがリリースされるときに一貫したパフォーマンス規則を提供する
新しい実験的な API は、API パフォーマンス モデルを導き出し始めているユーザーを魅了するでしょう。その後、パフォーマンス規則を変更すると、開発者は確実にイライラし、プログラムを書き直すことになる可能性があります。API が成熟した後は、パフォーマンス契約が変わらないことが重要です。実際、ほとんどの汎用 API (libc など) は、そのパフォーマンス契約が API の進化の過程で安定してきたことが部分的にその理由となっています。APIポートについても同様です
API プロバイダーは、新しいバージョンを定期的にテストして、パフォーマンスに問題が生じていないかどうかを確認することを期待する人もいるかもしれません。残念ながら、そのようなテストはほとんど実行されません。ただし、API の依存部分に対して独自のテストを実行できないという意味ではありません。プロファイラーを使用すると、通常、プログラムが少数の API に依存していることがわかります。新しいバージョンの API の記録されたパフォーマンスを以前のバージョンと比較するパフォーマンス テスト ツールを作成すると、新しいバージョンの API がリリースされると、プログラマー自身のコードのパフォーマンスが変化するという早期警告をプログラマーに与えることができます。
多くのプログラマは、コンピュータとそのソフトウェアが時間の経過とともに一貫して高速化することを望んでいます。実際、サプライヤーがこれを保証することは非常に困難ですが、サプライヤーは顧客にその通りであることを納得させるでしょう。多くのプログラマーは、グラフィックス ライブラリ、ドライバー、およびハードウェアの新しいバージョンによってすべてのグラフィックス アプリケーションのパフォーマンスが向上することを期待しており、複数の機能の改善に熱心に取り組んでいますが、古い機能のパフォーマンスがわずかであっても低下することがよくあります。
また、API 仕様によってパフォーマンス契約が明示され、コードを使用、変更、移植する人が契約を遵守できるようになることも期待できます。関数による動的メモリ割り当ての使用は、暗黙的か自動かにかかわらず、API ドキュメントの一部である必要があることに注意してください。
3 防御的なプログラミングが役立つ
プログラマは、パフォーマンスが未知であるか変動性の高い API を呼び出すとき、特にフォールト パフォーマンスが懸念される場合に、特別なアプローチを使用できます。初期化をパフォーマンスが重要な領域の外に移動し、API が使用する可能性のあるキャッシュされたデータ (フォントなど) をプリロードすることを試みることができます。パフォーマンスに大きな違いがある API や、内部にキャッシュされたデータが大量にある API は、これらの構造を割り当てまたは初期化する方法に関するヘルパー関数を提供することで、アプリケーションから API にヒントを渡すことができます。サーバーに時々 ping を送信するプログラムは、使用できない可能性のあるサーバーのリストを作成し、長時間のダウンタイムを回避できます。
4 APIで公開されるパラメータ調整
一部のライブラリは、パフォーマンスに影響を与える明示的な方法 (ファイルに割り当てられるバッファのサイズ、テーブルの初期サイズ、キャッシュのサイズの制御など) を提供しており、オペレーティング システムにはチューニング オプションも用意されています。これらのパラメーターを調整すると、パフォーマンス規約の制限内でパフォーマンスを向上させることができます。調整によって全体的な問題を解決することはできませんが、パフォーマンスに重大な影響を与える可能性がある、ライブラリに埋め込まれている固定オプションを減らすことができます。
一部のライブラリは、同じセマンティクスを持つ関数の代替実装 (通常は汎用 API の具体的な実装) を提供します。最適な具体的な実装を選択することによるチューニングは多くの場合非常に簡単で、Java コレクションはこの構造の良い例です。
API はアプリケーションに動的に適応するように設計されることが増えており、プログラマーは最適なパラメーター設定を選択する必要がなくなりました。ハッシュ テーブルがいっぱいになると、自動的に拡張され、再ハッシュされます (これは利点ですが、場合によってはパフォーマンスが低下することがあります)。ファイルが順次読み取られる場合、より大きなチャンクでの読み取り用に、より多くのバッファを割り当てることができます。
5 パフォーマンスを測定して仮説をテストする
一般的なアプローチは、重要なデータ構造を計測して、各構造が正しく使用されているかどうかを判断することです。たとえば、ハッシュ テーブルがどの程度完全であるか、またはハッシュの衝突がどのくらいの頻度で発生するかを測定できます。あるいは、書き込みパフォーマンスを犠牲にして読み取りが高速な構造が、実際には書き込みよりも読み取りの方が多いことを検証することもできます。
これらはいずれも、完璧主義者がダッシュボードや測定を自動化するツールを開発したり、パフォーマンス測定でパフォーマンス規則への準拠を確立できるようにパフォーマンス規則を詳細に説明する方法を開発したりすることを妨げるものではありません。これらの目標を達成するのは簡単ではなく、見返りも大きくないかもしれません。
多くの場合、最初にソフトウェアをインストルメントしなくてもパフォーマンス測定を実行できるため、問題を追跡する必要がある前に作業が必要ないという利点があり、コードまたはライブラリへの変更がパフォーマンスに影響を与えるときに発生する問題の診断にも役立ちます。プロファイリングを定期的に実行して、パフォーマンスの偏差を信頼性の高い基準で測定します。
6 ログを使用して異常を検出し記録する
分散型サービスが複雑なシステムを構成すると、履行契約の違反が増加します。ネットワーク インターフェイス経由で提供されるサービスには、許容可能なパフォーマンスを指定する SLA が設定されている場合があることに注意してください。多くの構成では、測定プロセスは、SLA が満たされていることを確認するために、不定期にサービス要求を行います。これらのサービスは API 呼び出しと同様のメソッド (たとえば、リモート プロシージャ コール、または XML-RPC、SOAP、REST などのそのバリエーション) を使用するため、パフォーマンス契約が期待される場合があります。アプリケーションはこれらのサービスの障害を検出し、通常は適切に応答します。
ただし、応答性が遅いと、特に相互に依存するサービスが多数存在する場合、システムのパフォーマンスがすぐに低下する可能性があります。これらのサービスの顧客が期待するパフォーマンスを文書化し、問題の診断に役立つログを生成できれば便利です (これは syslog の用途の 1 つです)。ファイルのバックアップが不当に遅いように見える場合、昨日よりも遅くなっているのでしょうか? 最新の OS ソフトウェア更新前よりも遅くなりましたか? バックアップ デバイスが複数のコンピュータで共有される可能性があることを考えると、予想よりも遅いですか? それとも、何らかの納得のいく説明があるのでしょうか（例：バックアップシステムが破損したデータ構造を発見し、それを再構築するために長いプロセスを開始するなど）？
不透明なソフトウェア構成におけるパフォーマンスの問題を診断すると、パフォーマンスをレポートしたり、構成を構成するモジュールや API のソース コードや詳細が欠如している場合に問題を発見したりするのに役立ちます。パフォーマンスの問題はソフトウェア内で解決することはできませんが、オペレーティング システムとネットワークに調整や修正を加えることができます。ディスクがほぼ満杯であるためにバックアップ デバイスが遅い場合は、必ずディスク領域を追加してください。優れたロギングと関連ツールは役に立ちますが、残念なことに、ロギングはコンピュータ システムの進化において過小評価され、見落とされている領域になる可能性があります。
確かに、パフォーマンス契約は機能的正確性契約ほど重要ではありませんが、ソフトウェア システムの重要なユーザー エクスペリエンスのほとんどすべてがパフォーマンス契約に依存しています。