昼夜を問わず、9時から9時まで働き、幾多の困難を乗り越え、ついにシステムの予定機能の開発を完了し、テストに合格し、オンラインに展開しました。あなたは自己満足を感じていますか、人生の頂点に達しましたか、そして無敵であることについて歌うことがどれほど孤独であるか.
現実には、システムがビジネスに対応できず、誰も使用しない場合、そのシステムはなくなってしまいます。人が増えたら、どんどん使ってください。ユーザーとビジネス データの増加に伴い、システムのパフォーマンスの問題が明らかになります。これらの問題の最適なソリューションと監視には、多くの場合、特定の機能の開発よりも高度で包括的な技術的品質と機能が必要です。
1. パフォーマンスの問題の監視
Guoyun おじさん: パフォーマンスの問題は隠されています. 優れたサーバー ハードウェア パフォーマンスは、優れたシステム サービス パフォーマンスを意味するわけではありません. 経験の浅い学生には理解するのが難しいかもしれません。システムが遅いだけではありませんか、ユーザーは教えてくれますか? サーバーの監視を行っていますが、CPU やメモリがいっぱいになると、監視アラームが発生しますか?
まず第一に、ユーザーはシステムが遅いとは言わないかもしれません.競合製品よりもはるかに遅い場合、ユーザーは自分の足で投票します. そして、ハードウェアがボトルネックになる前に超高速なシステムを開発する場合は、おじいちゃんの膝を受け入れてください-_-||
一般的なパフォーマンスの問題は、多くの場合、パフォーマンスの考慮事項の欠如によって引き起こされます. 応答は非常に遅いですが、ハードウェアの使用率は 5% 未満である可能性があります. この種の問題は、郭おじさんの主要な議論でもあります.
経験上、パフォーマンスの問題を監視して早期に警告しても、特定のパフォーマンスの問題を解決することは困難です。実際には、システム パフォーマンスの問題をスクリーニングし、末期症状を回避するための日常的なメカニズムが必要です。
データベース スロー クエリ ログ -長期的なデータベース操作の記録を記録する重要な監視方法です。スロー クエリ ログは、手動または自動で分析して、パフォーマンスの問題の可能性をスクリーニングできます。主流のデータベースはすべて、スロー クエリ ログの生成をサポートしています。具体的な構成方法については、ここでは説明しません。非統計データ操作は、通常 100 ミリ秒未満である必要があります。
インターフェイス パフォーマンスの監視 -通常、バックグラウンド システムはサービス インターフェイスを介してサービスを提供し、フロントエンド ページまたはモバイル デバイスは、サーバー インターフェイスを呼び出して対応する操作を完了します。インターフェイスの粒度はデータベース操作の粒度よりも大きく、インターフェイス呼び出しには多くのデータベース呼び出しが含まれる場合があります。ほとんどの場合、ユーザーによる操作アクションはサービス インターフェイス (保存、確認など) に対応するため、インターフェイスのパフォーマンスはユーザー エクスペリエンスにより近くなります。遅いクエリがない場合、インターフェイスのパフォーマンスが要件を満たしていない可能性があります. たとえば、インターフェイスがループで 1000 のデータベース操作を呼び出しているか、サードパーティのインターフェイスを呼び出しているなどの理由が考えられます. インタフェースの性能監視は、原則として、通話終了時刻からエントリ時刻を差し引いた総消費時間を算出し、タイムスクリーニングのためにこの消費時間を記録します。Spring のスライス機能は、この要件を簡単に満たすことができます。非レポート、エクスポート クラス インターフェイス、郭おじさんは 1 秒以内に完了する必要があると考えています。
メッセージ キューイング——システムがメッセージ キューイングと同様のメカニズムを使用している場合は、キューにキューに入れられたメッセージの数も監視する必要があります.メッセージが蓄積する場合は、この段階でシステムの全体的な消費容量が満たされなくなったことを意味します要求を入力します。
上記の 3 つのモニタリング ディメンションは重複せず、同時に実行する必要があります。
2. パフォーマンスの問題の位置付け
特定の SQL が遅いことを明確に示すことができるデータベースの遅いクエリ ログに加えて、上記の他の 2 つの状況は、場所の粒度が比較的大きく、インターフェイスまたは処理コードに対応していることを直接示している可能性があります。
より詳細な問題を特定するための具体的な方法も考えやすい、つまり、セグメント出力の各段階に時間がかかるということです。たとえば、100 行のメソッドの場合、これら 3 つのセグメントの実行時間をそれぞれ 30 番目、60 番目、100 番目に計算してログに記録できます。繰り返し、最終的に問題を特定できます。
パフォーマンスの問題の場所には、ある程度のパフォーマンスの常識が必要です. いわゆるパフォーマンスの常識とは、通常、タスクを完了するのに必要な時間がそれほど正確である必要はありませんが、大きさは明確でなければならないことを意味します. たとえば、データベース操作には通常数十ミリ秒かかり、メモリとのやり取りにはナノ秒またはマイクロ秒かかり、サードパーティ システムとのインターフェイスには数百ミリ秒から数秒かかる場合があります。これらの経験により、時間がかかることが合理的であるかどうかについての基本的な判断を下すことができます。例えば、50ミリ秒のデータベース操作の場合、100回ループするのに5秒かかります.これはすでに非常に遅い.バッチ操作に組み合わせることができるかどうかを検討できます.
3. アプリケーションのパフォーマンス最適化方法
リモート呼び出しの合体 -経験に基づくと、実際には、データベース操作のループ、またはサードパーティ システム インターフェイスへの呼び出しのループは、パフォーマンスの問題の非常に一般的な原因です。このような問題の最適化方法は、通常、バッチ操作を使用して呼び出しを最適化する方法です。たとえば、データベースで過去 1 年間の郭おじさんのチェックイン レコードをクエリする必要がある場合、正確な日付を使用して 365 回クエリを実行するか、時間範囲を使用して一度に 365 レコードをクエリすることができます。この方法は、以前の方法よりもはるかに高速です。メソッドが複雑で時間がかかる場合は、そこから必要なパブリック データを抽出し、統合されたバッチ クエリを実行し、バックアップ用にメモリに格納できます。これは、使用されている場所を検索するよりもはるかに高速です。同様に、書き込み操作と変更操作は、可能な限りバッチで実行する必要があります。
キャッシュを使用する -アクセス頻度の高いデータはメモリに格納でき、ハードディスクよりもメモリアクセスがはるかに高速であるという特徴を利用してアクセス速度を高速化できます。一般的なシナリオには、さまざまなカウント (郭おじさんの記事が表示された回数) が含まれます。
マルチスレッド並列処理 —マルチスレッドを使用してシリアルを並列に変更します。たとえば、デバイスと通信して状態をクエリし、デバイスを 1 つずつクエリし、同時にデバイスと並行してクエリを実行すると、後者の方がはるかに高速です。実際には、ほとんどの操作は IO で時間がかかるため、マルチスレッド化によりパフォーマンスが効果的に向上し、「空」などを回避できます。マルチスレッドの並列処理では、スレッドの同期に注意する必要があります。
4. データベースのパフォーマンスの最適化
データベースは、最新のすべてのシステムが依存するコンポーネントであり、そのパフォーマンスの問題に対する解決策も、開発者が習得する必要があるものです。
インデックスの追加 -インデックスの追加は、データベースを最適化するための推奨ソリューションです。原則は、空間を時間と交換することです。現在、ストレージのコストは急速に低下しており、基本的にすべての通常のビジネス データ クエリにインデックスを付けることができます。複雑な SQL の場合、実行計画を通じて分析できるインデックスを追加する方法を分析する必要がある場合があります。
ロック待機 -データベースにはロックの概念があります. トランザクションが X ロックを占有し、コミットされない前に、他のトランザクションはそのレコードを操作できず、待機することしかできません. 一意のインデックスを使用しないデータベース書き込み操作は、テーブル全体に書き込みロックを追加する可能性があり、送信前にテーブル レコード全体を操作することはできません。したがって、データベースのロックに注意し、夜間にロックし、できるだけ早くロックを解除し、できるだけ小さな領域にロックする必要があります。実際には、長いトランザクションの場合は、更新操作を後方に移動し、時間のかかる非トランザクション操作 (依存しないサードパーティ インターフェイスなど) を削除しようとすることが推測できます。取引。
トランザクション分離レベル -適切なトランザクション分離レベルを選択します。トランザクション分離レベルはデータベース ロックに関連しています。たとえば、最も厳格なシリアル分離レベルなどです。すべてのトランザクションがシリアルに実行されます。広く使用されているデータベース MYSQL にはデフォルトの分離レベル"repeatable read"がありますが、これによりギャップ ロックが制限され、ロック プリエンプションの可能性が高くなります。特に何もなければ、実際の状況に応じて「読み取りコミット」に調整できます
中間結果 -本質はデータベース レベルのキャッシュとして理解できます. 一部の結果がすべてのレコードから計算されると、データ量が膨大になり、時間がかかります. バッチで計算し、中間結果を保存できます。データ取得を高速化します。たとえば、昨年の郭おじさんの家族の総支出を計算するには、各レコードを合計するか、月に 1 回計算することができるため、過去 12 か月の支出の合計をクエリするだけで済みます。