データキャッシング、おそらく最後に使用すべきもの
最近、私は人気のあるeコマース用PHPパッケージとかなり対立しました。 その結果、Webアプリケーションのアーキテクチャにおける1つのよくある間違いについてお話ししたかったのです。
私が頻繁に使用するキャッシングで作業したパッケージ。 一部の「オプション」キャッシュ設定が含まれていない場合、1秒あたり10ページを超えるページを提供できませんでした。 明らかに、このようなパフォーマンスでは、実際にはオプションではなく、必須です。
memcachedのようなすばらしいツールがある場合、それを使用してパフォーマンスの問題を解決したいだけだと思います。 しかし、多くの場合、最初に使用しようとしているツールではありません。 理由は次のとおりです。
- すべてのユーザーでキャッシュが機能しない場合があります-ページを開くと、すぐにロードされます。 しかし、これはすべてのユーザーに当てはまりますか？ キャッシュを使用すると、ほとんどの訪問者のロード時間を最適化できますが、実際には、例外なくすべての人がページをすばやくロードする必要があります（ シックスシグマの原則に従う場合）。 実際には、リクエストは常に同じユーザーのキャッシュを見逃す可能性があり、状況をさらに悪化させます。長いショッピング履歴、その結果、ストアはアクティブなバイヤーだけのためにゆっくりと働きました）。
- キャッシュを使用すると、問題の解決から遠ざかることができます。最も遅くロードされるページを見て、最適化を試みます。 ただし、ここでのコツは、実際にはパフォーマンスの問題が別の領域にある可能性があることです（再び6シグマ）。 たとえば、ページ全体をキャッシュすることで問題を「修復」しますが、パフォーマンスの問題自体はどこにも行かず、隠されたままになります（他のページに何度もポップアップするため、トランスレーターに注意してください ）。
- 実際にキャッシュを管理するのは簡単な作業ではありません -「 暴走キャッシュ 」や、多数のキャッシュ要素が同時に無効になっている状況で苦労したことはありませんか？
キャッシングは、多くのアプリケーションが存続できない負担としてみなされるべきです。 簡単に適用できる最適化手法の武器をすべて使い果たすまで、この負担を避けるようにしてください。
最適化に入る前に、次の非常に単純なリストを確認してください。
- 各リクエストの実行計画を理解していますか？ そうでない場合は、long_query_time = 0に設定し、mk-query-digestコマンドを使用してクエリの完全なリストを取得します。 それぞれについてEXPLAINを実行し、実行計画を分析します。
-SELECT *を使用して、列の小さなセットのみを使用しますか？ または、データベースから多くの行を選択しますが、それらの一部のみを使用しますか？ その場合、選択するデータが多すぎて、インデックスの使用など、DBMSレベルの最適化が制限されます。
-1ページの生成に使用するクエリの数を知っていますか？ それらはすべて本当に必要ですか？ これらのリクエストの一部を単一のリクエストに変更したり、完全に削除したりすることは可能ですか？ （ 翻訳者のメモ ：非常に一般的な問題です。ページにクラスの学生のリストが表示され、その後、各学生のサイクルでクラスの名前を含む追加情報が要求されたケースを本当に知っています。変更後、要求の数は61から3に減少しました）。
結論として、「最適化によってアプリケーションの複雑さが軽減されることはほとんどありません。 本当に最適化する必要があるもののみを最適化することで、合併症を回避しようとします」 -Justinのスライドからの引用-instrumentation-for-php 。
長期的な観点から見ると、多くのアプリケーションはアーキテクチャをシンプルに保ち、「本物の少年がやるような」問題を解決する誘惑に負けないようにする必要があります。
ご注意 翻訳者 ：少し前の非常にリアルな対話：
-パフォーマンスに問題があるため、ログイン用にキャッシュ、垂直分割、NoSQL DBを追加する必要があります
-みんな-ここでEXPLAINを調べました-4,000行のフルスキャンクエリがあり、インデックスを作成しようとしましたが、すべてが26倍高速化されました。
翻訳に関するいくつかのメモ
1.キャッシュスタンプという用語-私はそれを暴走キャッシュとして翻訳しました（「漏れ」として翻訳する誘惑でしたが、それは間違っています）。 要するに、これは、たとえば、特定のクエリが十分に長く実行され、このクエリの結果がキャッシュされ、遅かれ早かれこのデータがキャッシュを離れ、このデータが必要な10ページが同時にレンダリングされ、代わりに10の遅いクエリがデータベースに送信される状況です一つ。 通常、キャッシュからスローされる前にデータを要求することで、これに苦労します。 例えば見てください
2.この記事では 、データをキャッシュする必要がないとは言っていないことに注意してください。 それらをキャッシュする必要がありますが、データベースクエリを最適化するいくつかの簡単な方法を試してからです。 つまり、シンプルなものから始める必要があります。
この間違いは何ですか？
私が頻繁に使用するキャッシングで作業したパッケージ。 一部の「オプション」キャッシュ設定が含まれていない場合、1秒あたり10ページを超えるページを提供できませんでした。 明らかに、このようなパフォーマンスでは、実際にはオプションではなく、必須です。
memcachedのようなすばらしいツールがある場合、それを使用してパフォーマンスの問題を解決したいだけだと思います。 しかし、多くの場合、最初に使用しようとしているツールではありません。 理由は次のとおりです。
- すべてのユーザーでキャッシュが機能しない場合があります-ページを開くと、すぐにロードされます。 しかし、これはすべてのユーザーに当てはまりますか？ キャッシュを使用すると、ほとんどの訪問者のロード時間を最適化できますが、実際には、例外なくすべての人がページをすばやくロードする必要があります（ シックスシグマの原則に従う場合）。 実際には、リクエストは常に同じユーザーのキャッシュを見逃す可能性があり、状況をさらに悪化させます。長いショッピング履歴、その結果、ストアはアクティブなバイヤーだけのためにゆっくりと働きました）。
- キャッシュを使用すると、問題の解決から遠ざかることができます。最も遅くロードされるページを見て、最適化を試みます。 ただし、ここでのコツは、実際にはパフォーマンスの問題が別の領域にある可能性があることです（再び6シグマ）。 たとえば、ページ全体をキャッシュすることで問題を「修復」しますが、パフォーマンスの問題自体はどこにも行かず、隠されたままになります（他のページに何度もポップアップするため、トランスレーターに注意してください ）。
- 実際にキャッシュを管理するのは簡単な作業ではありません -「 暴走キャッシュ 」や、多数のキャッシュ要素が同時に無効になっている状況で苦労したことはありませんか？
代替アプローチ
キャッシングは、多くのアプリケーションが存続できない負担としてみなされるべきです。 簡単に適用できる最適化手法の武器をすべて使い果たすまで、この負担を避けるようにしてください。
これらの方法は何ですか？
最適化に入る前に、次の非常に単純なリストを確認してください。
- 各リクエストの実行計画を理解していますか？ そうでない場合は、long_query_time = 0に設定し、mk-query-digestコマンドを使用してクエリの完全なリストを取得します。 それぞれについてEXPLAINを実行し、実行計画を分析します。
-SELECT *を使用して、列の小さなセットのみを使用しますか？ または、データベースから多くの行を選択しますが、それらの一部のみを使用しますか？ その場合、選択するデータが多すぎて、インデックスの使用など、DBMSレベルの最適化が制限されます。
-1ページの生成に使用するクエリの数を知っていますか？ それらはすべて本当に必要ですか？ これらのリクエストの一部を単一のリクエストに変更したり、完全に削除したりすることは可能ですか？ （ 翻訳者のメモ ：非常に一般的な問題です。ページにクラスの学生のリストが表示され、その後、各学生のサイクルでクラスの名前を含む追加情報が要求されたケースを本当に知っています。変更後、要求の数は61から3に減少しました）。
結論として、「最適化によってアプリケーションの複雑さが軽減されることはほとんどありません。 本当に最適化する必要があるもののみを最適化することで、合併症を回避しようとします」 -Justinのスライドからの引用-instrumentation-for-php 。
長期的な観点から見ると、多くのアプリケーションはアーキテクチャをシンプルに保ち、「本物の少年がやるような」問題を解決する誘惑に負けないようにする必要があります。
ご注意 翻訳者 ：少し前の非常にリアルな対話：
-パフォーマンスに問題があるため、ログイン用にキャッシュ、垂直分割、NoSQL DBを追加する必要があります
-みんな-ここでEXPLAINを調べました-4,000行のフルスキャンクエリがあり、インデックスを作成しようとしましたが、すべてが26倍高速化されました。
翻訳に関するいくつかのメモ
1.キャッシュスタンプという用語-私はそれを暴走キャッシュとして翻訳しました（「漏れ」として翻訳する誘惑でしたが、それは間違っています）。 要するに、これは、たとえば、特定のクエリが十分に長く実行され、このクエリの結果がキャッシュされ、遅かれ早かれこのデータがキャッシュを離れ、このデータが必要な10ページが同時にレンダリングされ、代わりに10の遅いクエリがデータベースに送信される状況です一つ。 通常、キャッシュからスローされる前にデータを要求することで、これに苦労します。 例えば見てください
2.この記事では 、データをキャッシュする必要がないとは言っていないことに注意してください。 それらをキャッシュする必要がありますが、データベースクエリを最適化するいくつかの簡単な方法を試してからです。 つまり、シンプルなものから始める必要があります。
All Articles