（Web）アプリケーションを最適化するアプローチ

私はあなたのことを知りません、私は個人的にプログラムのパフォーマンスを最適化するのが大好きです。 プログラムが遅くならず、サイトがすぐに開くときが大好きです。 この記事では、パフォーマンスを改善するためのいくつかの（基本的な）アプローチを紹介します。 基本的に、これらはWebアプリケーションに関連していますが、「通常の」プログラムにはいくつかのことが当てはまります。 プロファイリング、バッチ処理、リクエストの非同期処理などのトピックを扱います。このトピックは、 「MySQLを使用してWebアプリケーションを最適化するための戦略」の続きと考えることができます 。

いつ最適化する必要がありますか？

最適化を開始する前に最初に自問する必要がある最初の質問は、現在のパフォーマンスが自分に合っているかどうかです。 たとえば、ゲームを開発している場合、「平均」ハードウェアおよび「中」設定での最小FPSはどれくらいですか？ たとえば30を下回った場合、プレイヤーはそれに気づくでしょう。 平均フレームレートが60 FPSであっても、ゲームの雰囲気を決定するのは最小のFPSです-「減速」または「スムーズに動作」。 これがWebサイトの場合、ユーザーがページを開く時間はどれくらいですか？ この時間が一瞬の場合、ユーザーはよりアクティブになり、サイトでの作業に満足するでしょう。

自分（または上司、ヘヘヘ）が現在のアプリケーションのパフォーマンスに満足していないことを理解しているとします。 どうする

1.測定する

最適化は数字で始まる必要があります 。 アプリケーションの個々のフラグメントの実行時間がない場合、効率的に最適化できません。 何が起こっているかを完全に把握していないため、実際にスローダウンするフラグメントよりも最適化が容易なフラグメントを長時間最適化できます。

開発時には、プロファイリングを使用してボトルネックを特定すると便利な場合がよくあります。 例えば、PHPの場合、Facebookのxhprofという優れたプロファイラーがあります（ 彼らはここで何度も 書いています）。 大規模で馴染みのないプロジェクトがある場合、プロファイラーは、コードのボトルネックがある場合、それをすばやく見つける唯一の方法です。 ただし、「通常の」プロファイラーは、いくつかの理由により、日常の開発ではほとんど使用されません。
-最も「良い」プロファイラーでさえ、アプリケーションの速度を大幅に低下させます
-結果を得るには、別の場所に行くか、個々の視聴者を実行する必要があります
-結果自体をどこかに保存する必要があります（通常、プロファイリングデータはかなりのスペースを占有します）。

これらの（および、おそらく他の）理由により、Web開発用の個別のプロファイリングユーティリティの代わりとして、いわゆる「デバッグパネル」がサイトの開発バージョン（ 例 ）に組み込まれ、さまざまな概要（詳細を表示する機能）コードに直接組み込まれているメトリック。 通常、これはSQLクエリの実行回数と実行時間であり、他のサービス（memcacheなど）へのクエリの実行回数と実行回数はそれほど一般的ではありません。 ほとんどの場合、合計実行時間、サーバーからの応答のサイズ、および消費されるメモリの量も測定されます。

ほとんどのゲームでは、「デバッグコンソール」を有効にできます。このコンソールでは、原則として、FPSの数、シーン上のオブジェクトの数などを確認できます。 比較的最近まで、Minecraftには各フレームの時間の分布を示すダイアグラムが含まれていました。1つの色は「物理学」に費やされた時間を表し、もう1つの色はレンダリングに費やされました。

さまざまなものを測定できますが、Webプロジェクトでは、ほとんどの時間がデータベースまたは他のサービスへのアクセスに費やされます。 既成のフレームワークを使用していない場合、またはお気に入りのフレームワークにデバッグパネルが含まれていない場合、そのようなコードでもどこからでも開始できます。

<?php function sql_query($query) { $start = microtime(true); $result = mysql_query($query); $GLOBALS['SQL_TIME'] += microtime(true) - $start; return $result; } 

2.言った、測定！

よくやった、すべてがタイマーで覆われていて、開発環境ではすべてが素晴らしいが、本番ではすべてが違うのか？ だから、あなたは間違って測定している、またはおそらくすべてではありません...生産の生産性を測定するのはどうですか？ たとえば、PHPで記述する場合、UDPプロトコルで動作する実稼働環境でのパフォーマンスを測定するためのPinbaと呼ばれるすばらしいツールがあります。 このツールに基づいて、開発中にデバッグパネルを終了し、さらに「戦闘」環境でタイマーのリアルタイム統計を取得できます。 この方法でパフォーマンスを測定したことがない場合、サイトが実際にどのように機能するかについて多くの興味深いことがわかります。

サーバーからのページの戻り時間は100ミリ秒ですが、それでもページが長時間開いているという不満はありますか？ 出力のサイズとブラウザに組み込まれたパフォーマンスカウンターを測定します。 おそらくあなたのサイトは静的なデータを返すためにCDNを必要とします、たぶんあなたはただホスティングプロバイダーを変える必要があるだけです。 ボトルネックがどこにあるかを測定するまで、推測しかできません。

3.怠け者になる

多くの場合、このページのすべてのユーザーのコードには、大きくて不必要な何かの初期化があることがわかります。 たとえば、自動展開の手段として、天気予報のWeb要求ごとに異なるサイトに登る、またはプロジェクトのルートにある「git pull origin master」によって実行される大規模なinitメソッド。 パフォーマンス分析のプロセスでは、コードから単純に破棄するか、「ifでラップ」することができ、本当に必要な場合にのみ必要な部分を含めることができる多くのことに出くわします。

ページの大きなフラグメントが実質的に変更されないことが非常に一般的です（たとえば、ページの「ヘッダー」と「フッター」）。 この場合、明白な解決策は、事前にコンテンツを生成するか、キャッシュに入れて毎回再描画しないことです。

コードと実際の生活の中で怠けてください。 常に同じ作業を行わない（誰も必要としない）、ユーザーのリクエストに答えるために本当に必要なことのみを行い、残りは行わない、または誰かに委任しない（たとえば、「重い」が非常に敏感ではない）遅延するためには、物事をウェブ上で行うのではなく、cronに委任する必要があります。

4.（非同期）バッチ処理を使用する

さまざまなプロジェクトで、1つの要求ですべてを一緒に処理する代わりに、数十、数百のレコードを一度に1つずつ処理するという、ささいな設計エラーに対応できます。 たとえば、ページ上の30個の製品のデータを表示する必要がある場合、「SELECT ... FROM table WHERE id = ...」という形式の30のクエリではなく、「SELECT ... FROM table WHERE id IN（...）」という形式のクエリを1つ作成します。 ほとんどのデータベースでは、結果が30行のクエリと結果が1行のクエリ（！）の間に速度の違いはまったくありません。 原則として、バッチ処理を追加するために必要なコードの変更は非常に少なく、その代わりに、何百回も、時には何百倍も速度が向上します。 これは、SQLクエリだけでなく、外部または内部サービスへの呼び出しにも適用されます。 ネットワークに接続すると、常にリクエストの処理に大幅な遅延が発生するため、Webの状態でリクエストの数を最小限に抑えることが非常に望ましいです。

バッチ処理を高速化する別の方法は非同期です。 言語で許可されており、異なるサービスへの要求を1つにグループ化して非同期に実行できる場合、応答時間も大幅に短縮され、サービスが多いほどゲインが大きくなります。 これはMySQLにはあまり当てはまりませんが、たとえば低速のGoogle Datastore APIを使用する場合には十分に当てはまります。

5.複雑でわかりにくい混乱を単純化する

例を挙げましょう。何かを実行し、おそらく（おそらく）正しく実行するが、数百万行を同時にスキャンする、かなり遅い SQLクエリがあります。 複雑なSQLクエリを最適化するには、最初に単純化する必要があります。冗長なものをすべて、場合によってはテーブル全体またはネストされた選択を破棄します。 不要なものをすべて削除して初めて、意味のある最適化を実行できます。 そうしないと、無駄に多くの時間を費やしてフラグメントを最適化できますが、これは最終結果に影響しません。 多くの場合、特にMySQLを使用する場合、クエリをいくつかの単純なクエリに分割します。各クエリは元のクエリよりもはるかに高速に動作するため、満足のいくソリューションになります。

多くの人々によって開発されたシステムでは、明確で適切に設計されたコードの代わりに、「松葉杖を重ねる」ことがよくあります。 これは、プログラマーの資格が低い場合だけでなく、通常の反復開発でも発生します。ただし、一定のリファクタリングがない場合に限ります。 問題がこれらの場所のいずれかにあることがわかった場合、最初にコードのリファクタリングを少し行う必要があります。まず、その動作を理解し、次に、明らかに不要なものをすぐに最適化または破棄できます。 単にコードを整理しただけで、コードのパフォーマンスが満足できるものになり、対応するフラグメントの最適化が不要になることがよくあります。

6.「親愛なる」機能

0.1％のユーザーが使用する機能がありますが、同時にサーバーでの応答時間が半分になる機能があることを発見する可能性は十分にあります。 その場合、この機能を再考して他の「より安い」ソリューションを提供するか、この機能をデフォルトで無効にします。 ユーザーがそれを必要とする場合、彼はそれを再びつけます。

7.キャッシュ

他に何も役に立たない場合、または経時的に変化しないデータがある場合は、キャッシュしてください。 他のすべてのオプションが使い果たされた場合にのみキャッシュを使用する価値があると主張するのはなぜですか？ 事実、可変データをキャッシュに入れ始めるとすぐに、キャッシュの関連性を監視する必要がありますが、これは非常に難しいエンジニアリング作業です。

例：主キーIDでテーブルtableに個々のレコードをキャッシュします。 1つのレコード-「table_ <id>」形式のキャッシュ内の1つのキー。 ここで、特定の条件に対して複数のレコードを更新する必要があると想像してください（「テーブルを更新する<条件>」）。 この場合、キャッシュをフラッシュする方法は？ 単純だが非常に時間がかかる決定の1つは、この条件を事前に選択し、キャッシュ内のすべてのエントリをIDでフラッシュしてから、更新を行うことです。 しかし、select、キャッシュのフラッシュ、および更新の間に、別のリクエストが「ウェッジ」する場合はどうでしょうか？ このようなもの：

最初のリクエスト： 1. <condition>のテーブルからIDを選択します 2. memcacheの削除ID 6.テーブルセットの更新... where <条件>

2番目の並列クエリ： 3. memcache get "table_N"-空、キャッシュは既にリセットされています 4. id = Nのテーブルから...を選択します 5. memcache set "table_N"-古いデータをキャッシュに設定します

非常にきちんと記述されたコードのない1つではなく2つのデータソースの存在は、必然的にそれらの非同期化につながり、キャッシュの場合、サイト上の不整合または古いデータ、「壊れた」カウンターなどの不快なアーティファクトにつながります。

もちろん、生産性を向上させるためにキャッシュがうまく使用されている例は数多くありますが、ここでも他のすべてのオプションを検討した後です。 オペレーティングシステムでは、遅いメディアでの操作がキャッシュされます（読み取りは単にキャッシュされ、書き込みはバッファリングされ、データの破損やファイルシステム構造につながることがあります）。 これは作業速度に大きく貢献しますが、SSDとハードドライブを使用した場合のユーザーエクスペリエンスを比較したことがある場合、キャッシュにもかかわらず、後者を再び使用することは決してありません。 サイズの異なるメモリの速度は桁違いに異なるため、プロセッサは多くのキャッシュレベルを使用します（レジスタメモリへのアクセス時間を約1 ns、ハードディスクのアクセス時間を10ミリ秒と比較します-差は1000万倍です！） ウィキペディアから取られたイラスト）。

おわりに

そこで、主にPHP + MySQLバンドルを最も一般的なものとして、（Web）アプリケーションのパフォーマンスを向上させる基本的な方法を検討しました。 私は個人的に最適化のために上記のアプローチを使用しますが、これまでのところ、プロジェクトを何回も、時には何十回も高速化するために多くの努力なしで管理しました。 記事が最適化の方法を教えていない場合、少なくともそれがあなた（およびあなたの同僚）を正しい方向に押し進め、世界が少し良くなることを願っています。

*最初の図はこのページから取られています （Googleによる）