ソフトウェアパフォーマンス最適化の取り組みの計画と予算編成に最善のアプローチをとるには？
しばらくの間クライアントと一緒にいたソフトウェアシステムがあります。クライアントが本番環境で使用する、機能が豊富で成熟した複雑なエンタープライズアプリケーションの場合。クライアントのビジネスが急速に拡大しているため、対象のソフトウェアシステムはボリュームを効率的に処理できず、全体的なパフォーマンスはもはや顧客を満足させません。
そのため、顧客はソフトウェアシステムのベンダーにシステムのパフォーマンスと効率の改善を依頼します。顧客はまた、ベンダーが計画と球場の予算を準備することを期待しているため、そのような最適化のコストは大まかに事前にわかっています。
そのような計画と高水準の予算に対して、顧客のために準備できる最善のアプローチは何だと思いますか？私は以前にこの種の計画のいくつかを見たことがあり、そのような運動が一種の鶏が先か卵が先かというジレンマであるという事実のために、通常は非常に曖昧で不正確であるため、質問しています。複雑なシステムで何を正確に最適化および調整する必要があるかを知るためには、ベンチマーク、プロファイリング、および調査が必要です。そして、その調査も計画されたプロジェクトの一部であるため、そのようなベンチマーク結果が改善を実装するためにどのような努力を必要とするかを前もって知ることは不可能です。
私は彼らに正直になります。彼らがこれに資金を提供することを計画していて、パフォーマンスの問題を見つけるのに実際に多くの時間がかかる場合は、2段階で資金を提供する必要があることを伝えます。まず、調査、ベンチマーク、および分析を実行するために必要な作業を調査します。その努力の最終結果は、どの領域を最適化する必要があるかについての提案になる可能性があります。最も大金がかかる場所を見つけます。これは、機能の最適化、またはシステムのアーキテクチャのリファクタリング/変更である可能性があります。あなたはリスク/報酬を評価し、あなた/彼らがどれだけのパフォーマンス向上のために喜んで取るかを決定することができます。
彼らが最初のフェーズにお金を払う気がない場合は、提案/分析タイプの作業の一環として、自分で資金を提供する必要があるかもしれません。
そうすれば、フェーズ2のオプションを提供する準備を整えることができます。実際にパフォーマンスを最適化することができます。確かな推奨事項があり、実際に何らかの見積もりを提供できるようになります。
私はあなたに少し個人的な経験を与えることができるだけです。パフォーマンスに深刻な問題がある製品があり、人々は風に指を当てて問題が何であるかを推測することしかできませんでした。
私は何年にもわたってかなりの量のパフォーマンスチューニングを行ってきたので、マネージャーに試してもらいました。私は空中から数を引き出しました-4週間。
彼は懐疑的で、プロファイラーを設定するだけでもそんなに時間がかかるのではないかと言いました。私はプロファイラーを使用しないと言いました、私はただ 手動でサンプルを取ります 。彼は、有効な測定値を取得するのに十分なサンプルをどのように取得するのかと述べました。無限ループがある場合、いくつのサンプルが必要ですか？無限ではなく、長期的なものである場合、いくつ必要ですか？彼はあははと言って、私にゴーサインをくれた。
ビルド/デバッグ環境を自分のマシンにセットアップするだけで2週間かかりました。 2つの言語がありました（おそらく3つ、私は忘れます）。これで、問題を再現して手動のスタックサンプルをいくつか取得できるようになり、すぐに最初の問題を特定できました。最初のサンプルの採取から問題の特定まで、1時間もかかりませんでした。
ここで難しい部分があります。コードの所有者にコードを変更してもらうことです。最初の問題はそれほど難しくありませんでした。コードが修正され、実行時間が大幅に短縮されました。次に、さらにいくつかのサンプルを取り、2番目の大きな問題を見つけました。今回は、コードの所有者の協力を得るのはそれほど簡単ではありませんでした。必要な変更は、彼の「適切な設計」の概念に反していました。私の「政治的資本」は使い果たされたようです。ですから、私たちはできる限り成功しませんでした。 複数のステップを繰り返し続けることができれば、より大きなスピードアップが可能ですが、常に「非難ゲーム」の危険性があります。誰かが尋ねるかもしれないので、コードの所有者はそれを変更したくない場所ですそもそもなぜそのようにコードを作成しなかったのか。 パフォーマンスの問題がバグのようなものであることを伝えるのは難しい。誰でも作成でき、成人期の尺度でそれを認めることができる。
結論-推定4週間のうち、約3週間が費やされました。可能なスピードアップのいくつかを得ました。
教訓-これを行う場合は、設計変更を含む複数のコード変更を行う必要がある可能性があることをすべての開発者に説明する必要があります。さらに、変更は、以前の変更を無関係にするという意味で「無駄」に見える場合があります。あなたは彼らの賛同を得なければなりません。
修正する時間を見積もる前に、まずパフォーマンスブロックを特定する必要があります。ブロックの原因が、修正に時間がかからない、より多くのメモリと処理能力を備えた新しいサーバーが必要な場合。優れた機器を備えていても、データベースの基本設計に問題がある場合は、修正に1年以上かかる可能性があります。あるいは、物事にすばやくアクセスできるようにするために、データベースのパーティション分割が必要な場合もあります。
成熟した製品では、dbasが実行時間の長いクエリを見つけて、定期的に修正する必要があります。パフォーマンスチューニングは継続的に行う必要があります。さらに、開発者はおそらく技術的負債がどこにあるかについて良い考えを持っており、それはパフォーマンスの問題を探し始めるのに良い場所です。
パフォーマンスブロックを特定する時間を見積もり、問題がわかったら、問題を解決するための見積もりを準備することを伝えます。また、今すぐ始めて、実行時間の長いクエリを調べて修正します。それぞれの段階的な改善は、クライアントをあなたの側に保つのに役立ちます。また、パフォーマンスが最も遅い領域の優先リストを提供して、何から始めればよいかを理解してもらうこともできます。アプリケーションの特定の部分で問題を特定するのに1〜2週間費やし、次にそれらの問題を修正してから次のセクションに進むときに、対話型プロセスを提案することを検討することもできます。そうすれば、改善を開始できます。パフォーマンスの低下を引き起こしているすべてのアイテムを特定する前に。
特定の種類のSQL構造（これはデータベースバックエンドによって異なります）には既知のパフォーマンスの問題がありますが、SQLサーバーの場合、相関サブクエリ、カーソル、結合内の関数、where句、スカラーUDF、呼び出し元のビューなどを頻繁に使用する場合ビューを呼び出すビューの場合、データベースの大幅なオーバーホールが必要になる可能性があります。すべての外部キーがインデックスに登録されていない場合、それは簡単で安価な（時間の観点から）勝利です。開発者がsargableの意味を知らない場合は、クエリの記述が不適切である可能性が高く、ほとんどすべてのクエリで不適切なプラクティスを調べる必要があります。
率直に言って、あなたのクライアントがこれのためにいくらかのお金を喜んでお金を払うのは素晴らしいことです、しかしあなたは貧弱なデザインをしました、あなたの会社は修正の大部分を支払うべきです。
最後に、これから学ぶことを確認してください。問題がデータベースの設計不良またはクエリのパフォーマンスの低下である場合は、パフォーマンスの高いクエリを作成するように開発者をトレーニングするか、データスペシャリストを雇ってください。設計段階でデータスペシャリストなしでエンタープライズシステムを設計する人は誰でも、負荷が高くなるとシステムが失敗する可能性があります。データベースの設計段階では、パフォーマンスを考慮する必要があります。これは時期尚早の最適化ではなく、既知のパフォーマンスの問題を回避しています。成熟したエンタープライズシステムを本番環境で修正することは、悪い設計を修正することよりもはるかに困難です。
データベースがパフォーマンスの問題の唯一の原因であると言っているのではなく、データベースが最も可能性の高い場所の1つであるというだけです。何が起こっているかを確認するには、プロファイルを作成する必要があります。パフォーマンスの問題が発生し、アプリケーションが1回だけ呼び出す必要があるときに、ページごとに同じprocを何千回も呼び出していたことが判明したときのことを思い出すことができます。しかし、データスペシャリストとしての私の経験では、設計やパフォーマンスが不十分なデータベースが数多く存在します。