アプリケーションのパフォーマンスを低下させる方法-開発者の典型的な間違い

パフォーマンスは、最も重要な非機能アプリケーション要件の1つと見なされます。 この記事を読んでいる場合は、おそらくWebブラウザーやドキュメントを読むためのプログラムなどのアプリケーションを使用しているので、パフォーマンスの価値がどれほど素晴らしいかを実感できます。 この記事では、アプリケーションのパフォーマンスと、高いアプリケーションパフォーマンスの達成を不可能にする3つの開発者のミスについて説明します。

誤ったアプローチNo. 1.開発技術の理解不足

プログラミングの経験は関係ありません。高校を卒業したばかりか、長年の経験があるかもしれませんが、プログラムを開発する必要がある場合は、すでに開発済みのコードを見つけようとするでしょう。 もちろん、このコードは、使用するプログラミング言語と同じであることが望ましいです。



それには何の問題もありません。 このアプローチは、多くの場合、開発の高速化につながります。 一方、そうすることで、何か新しいことを学ぶ機会を失います。 このアプローチを使用すると、コードを適切に分析し、アルゴリズムだけでなくコードの各行の内部動作を理解するための時間を見つけることは非常にまれです。



これは、開発者が間違った方向に進んでいる状況の一例です。 ただし、このような方法は多数あります。 たとえば、私が若くてソフトウェア開発に精通し始めたとき、私はすべての上司を真似しようとしました。彼がしたことはすべて、完璧で間違いなく正しいように思えました。 私が何かをする必要があるとき、私はボスが同じことをするのを見て、可能な限り正確にすべての彼の行動を繰り返そうとしました。 私は彼のアプローチがなぜ機能したのか理解できなかったことが何度もありましたが、本当に重要なのでしょうか？ 主なことは、すべてが機能するということです！



割り当てられたタスクを解決するために可能な限り一生懸命働く開発者のタイプがあります。 原則として、彼らは既製のコンポーネント、コンポーネント、ブロックを探し、これらのすべての部品を組み立てれば完了です！ タスクが完了しました！ このような開発者は、見つかったコードフラグメントを調査して理解するために時間をかけることはめったになく、スケーラビリティ、メンテナンスの容易さ、パフォーマンスなどの「マイナー」なことをまったく気にしません。



開発者が問題に遭遇したことがない場合、プログラムの各コンポーネントがどのように機能するかを正確に理解しない別のシナリオが考えられます。 初めてテクノロジーを使用していて、問題がある場合は、このテクノロジーを詳細に研究し、最終的にその仕組みを見つけます。



テクノロジーの理解とその通常の使用の違いを理解するのに役立ついくつかの例を見てみましょう。 私は主に.NET *ベースのWebソリューションの開発に携わっているため、これについて説明します。

▍JavaScript*およびDOM

次のコード例を検討してください。 すべてがシンプルです。 コードは、DOMの1つの要素のスタイルを更新するだけです。 問題（現在のブラウザーでは、この問題はそれほど関連していませんが、私の考えを説明するのに非常に適しています）は、コードがDOMツリーを3回バイパスすることです。 コードが繰り返されると、ドキュメントが非常に大きく複雑になりますが、アプリケーションのパフォーマンスは大幅に低下します。









このような問題を修正するのは非常に簡単です。 次のコード例をご覧ください。 変数myFieldのオブジェクトを操作する前に、直接リンクが保持されます。 新しいコードはよりコンパクトで、読みやすく、理解しやすく、DOMツリーは1回しかアクセスされないため、より高速に動作します。









別の例を考えてみましょう。 この例はここから取られます 。



次の図は、2つの同等のコードフラグメントを示しています。 それぞれが1000個のli要素を持つリストを作成します。 右側のコードは各li要素にid属性を追加し、左側のコードは各li要素にクラス属性を追加します。









ご覧のとおり、コードフラグメントの2番目の部分は、作成された数千のli要素のそれぞれを単に参照しています。 Internet Explorer * 10およびChrome * 48で速度を測定しました。左側のコードの平均実行時間は57ミリ秒で、右側のコードの実行時間はわずか9ミリ秒で、大幅に短縮されました。 この場合、要素にアクセスするさまざまな方法によってのみ引き起こされるという事実にもかかわらず、違いは非常に大きくなります。



この例は非常に慎重に取るべきです。 この例では、セレクターをチェックする順序（ここでは右から左への順序）など、分析に関する多くの興味深い点がまだあります。 jQuery *を使用する場合は、DOMコンテキストについてお読みください。 一般的なCSSセレクターのパフォーマンスの原則については、 こちらをご覧ください。



最後の例はJavaScriptコードです。 この例はメモリに関連していますが、すべてが実際にどのように機能するかを理解するのに役立ちます。 ブラウザのメモリ消費量が多すぎると、パフォーマンスが低下します。



次の図は、2つのプロパティと1つのメソッドを持つオブジェクトを作成する2つの異なる方法を示しています。 左側では、クラスコンストラクターがオブジェクトに2つのプロパティを追加し、クラスプロトタイプを通じて追加のメソッドが追加されます。 右側では、コンストラクターはプロパティとメソッドの両方をすぐに追加します。



このようなオブジェクトを作成した後、これらの2つの方法を使用して数千のオブジェクトが作成されます。 これらのオブジェクトが使用するメモリ量を比較すると、Chromeの浅いサイズのメモリ領域と保持サイズのメモリ領域の使用に違いがあることがわかります。 プロトタイプアプローチでは、Shallow Size領域で約20％少ないメモリ（24 KBと比較して20 KB）、Retained Memory領域で66％少ないメモリ（60 KBと比較して20 KB）を使用します。



浅いサイズと保持サイズの詳細については、 こちらを参照してください 。



適切なテクノロジーの使用方法を知っているオブジェクトを作成できます。 特定のテクノロジーの仕組みを理解すると、メモリ管理とパフォーマンスの観点からアプリケーションを最適化できます。

▍LINQ

説明したトピックに関する会議でのスピーチの準備として、サーバーコードを使用した例を準備することにしました。 LINQは.NETの世界で新しい開発に広く使用されており、パフォーマンスを向上させる大きな可能性があるため、LINQ *を使用することにしました。



次の一般的なシナリオを検討してください。 次の図は、機能的に同等の2つのコードフラグメントを示しています。 コードの目的は、学校の各学部のすべての学科とすべてのコースのリストを作成することです。 Select N + 1というコードでは、すべての部門のリストを表示し、部門ごとにコースのリストを表示します。 これは、100のブランチがある場合、データベースへの1 + 100の呼び出しが必要であることを意味します。









この問題は別の方法で解決できます。 右側のコードスニペットには、1つの簡単なアプローチが示されています。 Includeメソッドを使用する場合（この場合、理解を容易にするためにハードコードされた文字列を使用します）、データベースへの呼び出しは1つだけで、この単一の呼び出しはすべての部門とコースをすぐに発行します。 この場合、2番目のforeachループを実行すると、各部門のすべてのCoursesコレクションが既にメモリ内にあります。



したがって、Select N + 1アプローチを避けるだけで、生産性を数百倍に高めることができます。



それほど明白でない例を考えてみましょう。 次の図では、2つのコードフラグメントの完全な違いは、2行目の宛先リストのデータ型です。 ここで疑問に思うかもしれません：宛先データのタイプは何かに影響しますか？ このテクノロジーの操作を学習すると、理解できます。宛先データのタイプによって、データベースクエリが実行されるタイミングが実際に決まります。 そして、これから、各リクエストのフィルターが適用される時間に依存します。



IEnumerableデータ型が予期されるコード＃1では、 Take Employee（10）が実行される直前にクエリが実行されます。 これは、1000人の従業員がいる場合、それらはすべてデータベースから取得され、その後10人が選択されることを意味します。









コード＃2では、 Take Employee（10）が実行された後にクエリが実行されます。 この場合、データベースから取得されるレコードは10個のみです。 次の記事では、異なるタイプのコレクションを使用する場合の違いについて詳しく説明します。

▍SQLServer

SQLでは、最高のデータベースパフォーマンスを実現するために多くの機能を学ぶ必要があります。 SQL Serverの操作は簡単ではありません。データの使用方法、最も頻繁に要求されるテーブル、およびフィールドを理解する必要があります。



それでも、生産性を向上させるために、次のような多くの一般原則を適用できます。

• クラスターまたは非クラスターインデックス。
• JOIN命令の正しい順序
• #tempテーブルと変数テーブルをいつ使用するかを理解する
• ビューまたはインデックス付きビューの使用。
• プリコンパイルされた命令の使用。

簡潔にするために、特定の例を挙げませんが、これらの原則は使用、分析、最適化できます。

thinking変化する思考

それでは、開発者はどのようにして考え方を変えて、No。

• 考えないでください：「私はインターフェイスデザイナーです」または「私は内部コード開発者です。」 おそらく、あなたはエンジニアであり、ある特定の分野に特化していますが、この専門分野を研究や他の分野を回避するために使用しないでください。
  
  
  
  
• 「スペシャリストに任せましょう。彼はより早く成功するからです。」 現代の世界では、柔軟性が使用されています。私たちは多機能のリソースである必要があり、知識が不十分な領域を研究する必要があります。
  
  
  
  
• 「これはわかりません。」と自問するのはやめましょう。 もちろん、それが単純であれば、誰もがすでに専門家になっていたでしょう。 読書、コンサルティング、勉強に時間を費やしてください。 それは簡単ではありませんが、遅かれ早かれ報われるでしょう。
  
  
  
  
• 「時間がありません。」と言うのをやめてください。 この異議は理解できます。 これはよく起こります。 しかし、かつてIntelの同僚が次のように言った：「何かに本当に興味があるなら、この時間があるでしょう。」 たとえば、土曜日の真夜中にこの記事を書いています！

誤ったアプローチNo. 2.特定の技術に対する選好

バージョン1.0以降、.NETで開発を続けています。 Webフォームのすべての機能と多くの.NETクライアントライブラリを詳細に知っています（一部を自分で変更しました）。 Model View Controller（MVC）のリリースについて知ったとき、私はそれを使いたくありませんでした：「私たちはそれを必要としません。」



実際のところ、このリストはかなり長く続けることができます。 私は最初は気に入らなかったもののリストを意味し、今では自信を持って頻繁に使用しています。 これは、開発者が一部の技術的ソリューションを支持し、他のソリューションを避ける傾向がある状況の一例にすぎません。これにより、生産性の向上が困難になります。



Entity FrameworkのオブジェクトへのLINQバインディング、またはデータのクエリ時のSQLストアドプロシージャに関する議論をよく耳にします。 1つまたは他のソリューションを使用することに慣れているため、どこでも使用しようとしています。



開発者の好みに影響を与えるもう1つの要因（一部の技術の選択と他の技術の拒否）は、オープンソースソフトウェアに対する個人的な態度です。 開発者は多くの場合、現在の状況に最適なソリューションではなく、自分の人生哲学とより一貫したソリューションを選択します。



時々、外部の要因（たとえば、厳しい締め切り）により、最適ではない決定が下されます。 最高のテクノロジーを選択するには時間がかかります。結論を読んで、試して、比較し、描く必要があります。 新しい製品または既存の製品の新しいバージョンを開発するとき、すでに遅れていることがよくあります。「期限は昨日です。」 この状況に対する2つの明らかな解決策は、余分な時間を要求するか、独学のために残業することです。

thinking変化する思考

間違ったアプローチ＃2を避けるために、開発者はどのように考え方を変える必要がありますか。

• 「この方法は常に機能した」、「私たちは常にそれを行った」などと言うのはやめてください。他のオプションを知って使用する必要があります。
  
  
  
  
• 間違ったソリューションを使用しようとしないでください！ 開発者は、望みの結果をもたらさない、またはできない特定のテクノロジーを頑なに適用しようとすることがあります。 開発者は多くの時間と労力を費やしますが、他のオプションを考慮することなく、何らかの形でこのテクノロジーを完成させ、結果に合わせて調整しようとします。 そのような恩知らずのプロセスは、「地球にフクロウを引っ張ろうとする試み」と呼ぶことができます。問題に焦点を合わせて、よりエレガントで迅速な別の解決策を見つけるのではなく、既存の不適切な解決策を適応させるためにあらゆる努力を払うことが望まれます。
  
  
  
  
• 「時間がありません。」 もちろん、常に新しいことを学ぶのに十分な時間はありません。 この異議は理解できます。

誤ったアプローチNo. 3.アプリケーションインフラストラクチャの不十分な理解

そのため、私たちは多くの努力を払い、最高のアプリケーションを作成しました。 展開に移りましょう。 すべてテスト済みです。 すべてがマシンで完璧に機能します。 10人のテスター全員が、アプリケーション自体とそのパフォーマンスに完全に満足していました。

したがって、今では問題が発生することはありません。すべてが完璧な状態になっていますか？



決して、すべてが完全に故障しているかもしれません！



次の質問を自問したことがありますか？

• アプリは負荷分散環境での作業に適していますか？
• アプリケーションはクラウドでホストされますが、このアプリケーションのインスタンスは多数ありますか？
• 私のアプリケーションの対象となるマシン上で実行される他のアプリケーションはいくつありますか？
• このサーバーで実行されている他のプログラムは何ですか？ SQL Server？ レポーティングサービス？ SharePoint *拡張機能はありますか？
• エンドユーザーはどこにいますか？ 彼らは世界中に分布していますか？
• 今後5年間で、アプリケーションには何人のユーザーがいますか？

これらの問題のすべてがインフラストラクチャに直接関連しているわけではありませんが、すべてに時間があります。 原則として、アプリケーションが動作する最終的な実際の条件は、中間段階のサーバーの条件とは異なります。



アプリケーションのパフォーマンスに影響を与える可能性のあるいくつかの要因を見てみましょう。 ユーザーが世界のさまざまな国にいるとします。 おそらく、米国のユーザーから苦情がなくても、アプリケーションは非常に迅速に動作しますが、ここではマレーシアのユーザーが低速に不満を言うでしょう。



このような問題を解決する方法はたくさんあります。 たとえば、データ配布ネットワーク（CDN）を使用して、そこに静的ファイルを配置できます。 その後、異なる場所にいるユーザーのページの読み込みが速くなります。 私が話していることを次の図に示します。









別の状況も考えられます。アプリケーションが、SQL ServerとWebサーバーを同時に実行するサーバーで実行されるとします。 この場合、CPU負荷が集中する2つのサーバーシステムが同じ物理サーバー上で実行されています。 この問題を解決するには？ インターネットインフォメーションサービス（IIS）サーバー上の.NETアプリケーションについて話している場合は、プロセッサマッチングを使用できます。 プロセッサマッチングは、1つのプロセスをコンピューターの1つ以上の特定のCPUコアにバインドすることです。



たとえば、4つのプロセッサを搭載したコンピューターでSQL ServerとIIS Webサーバーを実行するとします。









オペレーティングシステムに、SQL Serverに使用するCPUとIISに使用するCPUを決定させると、リソースを異なる方法で割り当てることができます。 各プロセッサー負荷に2つのプロセッサーが割り当てられる可能性があります。









また、4つのプロセッサすべてが1つの負荷にのみ割り当てられる可能性があります。









この場合、デッドロックが発生する可能性があります。IISは非常に多くのクエリを処理し、4つのプロセッサすべてを使用できますが、一部のクエリではSQLへのアクセスが必要になる場合があります。 実際には、このようなシナリオはまずありませんが、私のポイントを完全に示しています。



別の考えられる状況：1つのプロセスが同じCPUで常に機能しない。 多くの場合、コンテキストの切り替えが発生します。 コンテキストを頻繁に切り替えると、サーバー自体のパフォーマンスが低下し、このサーバーで実行されるアプリケーションのパフォーマンスが低下します。



この問題を解決する1つの方法は、IISとSQLに「プロセッサマッチング」を使用することです。 この場合、SQL Serverに必要なプロセッサの数とIISに必要なプロセッサの数を決定します。 これを行うには、IISのCPUカテゴリの[プロセッサコンプライアンス]セクションで設定を構成し、SQL Serverデータベースの[コンプライアンスマスク]を構成します。 これらのケースの両方を以下に示します。

CPU
制限（パーセント）	0
制限アクション	アクションなし
制限期間（分）	5
CPUマッチングが許可されました	偽
CPUマッチングマスク	4294967295
プロセッサコンプライアンスマスク（64ビット）	4294967295

このトピックは、Webファームを使用する場合など、生産性の向上に関連する他のインフラストラクチャ機能でさらに継続できます。

thinking変化する思考

第3の誤ったアプローチを避けるために、開発者はどのように考え方を変える必要がありますか？

• 「これは私の仕事ではありません。」 私たちのエンジニアは、顧客に最高のソリューションを提供するために、視野を広げる努力をしなければなりません。
  
  
  
  
• 「時間がありません。」 もちろん、私たちにはいつも時間がありません。 これが最も一般的な状況です。 時間の割り当ては、成功した経験豊富な優れた専門家を区別するものです。

ex言い訳をしないでください！

非難することは何もありません。 すべてがあなたに依存するわけではありません。 本当に一度起こる。 すべての家族、すべての趣味、誰もがリラックスする必要があります。

しかし、良い仕事は良いコードを書くことだけではないことを理解することが重要です。 ある時点で、説明した誤ったアプローチの一部またはすべてを使用しました。



これらを回避する方法は次のとおりです。

1. 必要に応じて、時間をかけてください-余裕を持って。 プロジェクトの作業に必要な時間を評価するように求められたら、時間をかけて調査とテストを行い、結論を下し、決定を下すことを忘れないでください。
2. テスト用の個人用アプリケーションを同時に作成してみてください。 このアプリケーションでは、開発したアプリケーションで実装する前に（または実装を拒否する前に）さまざまなソリューションを試すことができます。 時々間違いを犯します。
3. すでに適切な技術を所有している人々を見つけて、一緒にプログラミングしてみてください。 アプリケーションをデプロイするときにインフラストラクチャを理解している専門家と協力してください。 この時間は十分に費やされます。
4. スタックオーバーフローを避けてください！ 私の問題のほとんどはすでに解決されています。 回答を分析せずに単純にコピーすると、不完全なソリューションになります。
5. 自分自身を狭い専門家と見なさないでください。能力を制限しないでください。 もちろん、なんらかの分野の専門家になれば、これはすばらしいことですが、会話がまだ専門家ではない分野に関係している場合でも、会話を最新に保つことができるはずです。
6. 他の人を助けます！ これはおそらく学習する最良の方法の1つです。 他の人が彼らの問題を解決するのを手伝えば、最終的にあなたはあなた自身の時間を節約するでしょう。