生産事故の最適化経験

通常のイベントプロモーションの後、ユーザーは入札時にウェブページまたはアプリを開くことができないというフィードバックを次々に送り始めました。最初はすでに入札が行われていました。特に入札に興味があるのは、Xiaomi の携帯電話を手に入れるときも同じではないでしょうか。イベントが続くにつれて、金利クーポンや現金クーポンを受け取ったユーザーは、プラットフォームが詐欺的であり、資源を節約するために意図的に使用できないようにしていると信じて、入札を獲得することができずに強く抗議しました。

分析プロセス

実際、過去にもユーザーからのフィードバックが減らず、例としてXiaomiを利用して携帯電話を手に入れることで顧客が騙されたことがあり、今回はユーザーからのフィードバックが強すぎたため、当社はそのような事態に陥りました。真面目に受け取る。フロントエンド製品はアプリ、公式サイト、H5の計3つありますが、その中でもアプリが最も多く使われており、公式サイトは2番目に日常的には使用されませんが、トラフィックが急増します。イベント中 (イベントは通常、主に H5 ゲームであり、H5 はプロモーションやマーケティングにも便利です。)、3 つのフロントエンド製品はすべて lvs を使用して 2 つのバックエンド Webサービスサーバーにロードします (以下を参照)。今回はユーザーからのフィードバックは基本的にウェブ側とアプリ側にあるため、これら 4 つのサーバーの観察に重点を置きます。

まず、ネットワーク帯域幅がいっぱいなのかどうか疑問に思いましたが、入札プロセス中にツールを介してそれを監視するネットワークエンジニアを見つけましたので、最大帯域幅使用率はわずか約70％であったため、それを判断しました。もう一度、Web サーバーが耐えられないかどうかを疑って、top コマンドを使用して、入札の瞬間に 2 つのサーバーの負荷を確認します。入札後、アプリの 2 つのサーバーはピーク時に 10 ～ 12 に戻り、その後通常に戻ります。

Web サーバーのビジネス ログを追跡したところ、データベース 更新 レイヤーが、新しいデータベース接続を要求できなかったか、データベース接続の最大接続数が少なすぎると考えられたことを報告していることがわかりました。そのため、mysql データベース の最大接続数は過去の 3 倍に調整されました。次の入札競争中にビジネス ログを観察し続けたところ、データベース リンクに関連するエラーは報告されなくなっていることがわかりました。ユーザーは依然として、入札競争中にページを開けることができなかったと報告しています。

引き続き Web サーバーを追跡します。入札時にコマンド (ps -ef|grep httpd|wc -l) を使用して httpd 接続数を確認します。これは、Apache設定ファイルに設定されている最大接続数をランダムに確認します (Apache のデフォルト)。最大接続数は 256 です)、入札プロセス中の接続数が最大接続数に達したため、多くのユーザーが入札プロセス中に http 接続を取得できず、ページが応答しなくなったり、待機中のアプリ。そのため、Apache 設定ファイルの最大接続数を 1024*3 に調整します。

入札プロセス中に引き続き観察してください。カスタマー サービスのフィードバックによると、入札プロセス中に Apache 接続の数が依然として 2600 ～ 2800 に急増する可能性があります。ただし、入札の問題を報告するユーザーはまだ多くいますが、若干改善されています。以前よりも改善されましたが、散発的なユーザーのフィードバックはすでにターゲットを捉えていましたが、最終的にはロールバックされました。次に、データベース サーバーの観察を続け、top コマンドと MySQL Workbench を使用して、mysql メイン ライブラリとスレーブ ライブラリのさまざまな負荷を表示します (以下に示すように)。ピークに達しますが、スレーブ ライブラリにはそれほど大きな圧力はかかりません。

トラッキング コードにより、3 つの端のすべてのビジネス コードがメイン ライブラリに接続されており、バックエンドの querybusiness のみがスレーブ ライブラリから使用されていることが判明したため、変換はただちに開始されました。入札プロセス中のクエリ、他のページ、またはビジネスのすべてのクエリがスレーブ データベースからのクエリに変換されます。変換後、マスター データベースへの負荷が大幅に軽減され、スレーブへの負荷が大幅に軽減されることが観察されます。データベースが増え始めます。以下に示すように:

カスタマーサービスからのフィードバックによると、変更後、入札プロセス中にページが開かない、または開くのが遅いという問題は、ほぼ解消されました。 、しかし一部のユーザーは依然としてこれを報告しています この問題は、上記のプロジェクトの分析結果に基づいています:

• 1 負荷がかかっている 2 台のサーバーが処理制限に達したため、負荷を加えるためにさらに多くのサーバーを構成する必要があります。

• 2 mysql メインデータベースへの負荷は大幅に軽減されましたが、スレーブデータベースへの負荷は増加しました。現在の 1 つのマスターと 1 つのスレーブを 1 つのマスターと複数のスレーブ モード に変更する必要があります。

• 3 最適化ルール、評価用のテスト Web サイトがインターネット上に多数あります) など。

  当時のこれらの状況に基づいて最適化レポートを作成しました。以下を参照してください:

  最適化レポート

1 背景

会社のビジネスの継続的な発展に伴い、ビジネス量とユーザー数が急増し、公式ウェブサイトの pv も初期の xxx-xxx から現在の xxx-xxxx に増加し、アプリのアクティブ ユーザーが大幅に増加したため、プラットフォームの現在のテクノロジー

アーキテクチャ

に大きな課題をもたらしています。特に最近、プラットフォームの入札ソースが逼迫しているため、入札を完了するまでの時間がますます短くなってきています。サーバーに対する負荷も増大しているため、より多くのユーザーとビジネス ボリュームをサポートするには、現在のシステム アーキテクチャをアップグレードする必要があります。

2 ユーザーアクセスの概略図

現在、プラットフォームには、プラットフォーム公式Webサイト、プラットフォームAPP、プラットフォーム小規模Webページの3つの製品があり、その中で、プラットフォーム公式WebサイトとプラットフォームAPPは大きなプレッシャーにさらされています。 。

3 既存の問題

ユーザーが入札を競う際の問題は次の点に集中しています1. Web ページまたはアプリが開かない

2. 転送が成功した後、Web サイトまたはアプリが開くのが遅い

3.サーバー側に責任があるため、入札プロセスに大きな圧力がかかり、更新に失敗し、再度返金されました

4. データベース接続の数が枯渇したため、入札がいっぱいになった後、投資記録を追加できず、入札の進行状況が失敗しました。ロールバックされました

4. 分析

最近のサーバーパラメータ、同時実行性、システムログを分析することにより、詳細な分析を行った結果、次の結論が得られました:
1. プラットフォームの公式 Web サイトとプラットフォーム APP の入札プロセス中に、サーバーの負荷が高かった中でも、プラットフォーム APP の問題はより顕著であり、ピーク入札期間中、単一 APP サーバーの最大接続数は 2600 に近く、これは Apache の最大処理能力

に近くなります。データベース サーバーには大きな負荷がかかっています。データベースのプレッシャーは主に 2 つの期間で顕著です

1) プラットフォームがアクティビティを実行しているとき、公式 Web サイト、小さな Web ページ、アプリへのアクセス数が大幅に増加し、データベース処理時のデータ クエリ量が大幅に増加します。制限に達すると、ウェブサイトが開くのが遅いなどの問題が表示されます。

2) ユーザーが入札を競う場合、ユーザーに入札を競うプレッシャーは入札前と入札中の 2 つの段階に分けられます。入札前に、入札がすぐにいっぱいになるため、ユーザーは事前に入札ページを開いて継続的に更新します。これにより、入札を競うユーザーの数が非常に多い場合、データベースの接続数が増加します。入札プロセス中に、おそらく 1 回の購入に約 15 個のテーブルが含まれ、各入札には 1,000 万のシェアがあり、それぞれ約 100 ～ 200 人が購入して入札を完了します。時間は 150 人の中央値に基づいて計算され、数秒でデータは一定期間内に 2000 回から 300 回

0 回更新される必要があり (クエリを除く更新のみ)、大量の同時実行が発生します。これにより、更新の失敗や接続タイムアウトが発生する可能性があり、ユーザーの入札やシステムの通常の完全な入札に影響を与える可能性があります。

5つのソリューション

1. Webサーバーソリューション
Webサービスにアクセスする単一ユーザーの概略図

現在、WebサイトとプラットフォームAPPは責任のバランスをとるために2つのサービスを使用しており、各サーバーには

インストールされています

サーバー側の処理に使用され、各 Apache は最大約 2,000 の接続を処理できます。したがって、理論上、現在の Web サイトまたはアプリは 4,000 を超えるユーザー リクエストを処理できます。同時に 10,000 のリクエストをサポートしたい場合、それをサポートするには 5 つの Apache サーバーが必要となるため、現在 6 つの Web サーバーが不足しています。
サーバーアップグレード後のアクセス図

2. データベースソリューション

現在のデータベース展開計画

1) マスター/スレーブの分離により、メインデータベースのクエリ負荷の 80% が解決されます。現在、プラットフォームの公式 Web サイトとアプリは MySQL メイン データベースに接続されており、メイン データベースへの負荷が 2 倍になっています。サービス内のすべてのクエリをスレーブ データベースに移行すると、メイン データベースへの負荷が大幅に軽減されます。

2) キャッシュサーバーを追加します。スレーブ データベースのクエリがピークに達すると、マスターとスレーブの同期にも影響が生じ、トランザクションに影響を与えるため、データベースへのリクエストの負荷を軽減するために、ユーザーが頻繁に使用するクエリがキャッシュされます。

redis
クラスターを構築するには、
3つのキャッシュサーバーを追加する必要があります。

3. その他の最適化
1) 公式 Web サイトのホームページは静的に作成されます。cnzz の統計によれば、ホームページは、Web サイトへの総アクセス数の約 15% を占め、静的に処理されます。公式サイトを開く際のスムーズさを向上させます。

2) Apache サーバーを最適化し、gzip圧縮を有効にし、適切な数のリンクを構成します。

3) 投資プロセスの更新ホットスポット、つまり目標スケジュールを削除します。入札が成功または失敗するたびに、入札スケジュールを更新する必要があります。マルチスレッド更新中にオプティミスティック ロックなどの問題が発生する可能性があります。プロセス中に更新を削除し、入札が満額になった後にのみ入札スケジュールに入札進捗情報を保存することで、投資プロセス中のデータベースへの負担を最適化します。

6 サーバーアップグレード計画

1. プラットフォームに対する最大の負荷は、現在の 1 つのマスターと 1 つのスレーブを 1 つのマスターと 4 つのスレーブに変更する必要があります。公式 Web サイト/アプリ/小さな Web ページによって生成された多数のクエリは、仮想 IP によって 3 つのスレーブ データベースに分散され、バックグラウンド管理クエリは別のスレーブ データベースに送信されます。データベースには 3 つの新しいサーバーを追加する必要があります

2. データ負荷を軽減するためにキャッシュを増やす必要があります

3.ユーザーを細分化するために追加する必要があります アクセス要求

アプリは 2 つのサーバーを追加する必要があります アプリサーバーは入札プロセス中に最も大きな負荷がかかるため、構成の完了後に 2 つのサーバーを追加する必要があります

。公式 Web サイトにはサーバーを 1 つ追加する必要があります 公式 Web サイトには、入札プロセス中にある程度の圧力がかかります。完成した図は次のとおりです。

合計 8 つのサーバーが必要です。購入する必要がありますが、そのうち 2 つは大容量メモリ (64G 以上) を必要とします

ord バージョンの最適化レポートをダウンロードするにはクリックしてください

注: すべての最適化計画が実稼働環境に導入されると、問題は解決されます。安心してご入札いただけます！

---

著者: Pure Smile

出典: http://www.php.cn/
著作権は著者に帰属します、転載する場合は出典を明記してください

以上が生産事故の最適化経験の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。