前回の送信と読み込み速度のためにサーバーが画像をossサーバーにエスケープしたのは久しぶりです
画像がossサーバー最適化に転送される前後の結果については、クリックして表示する前に私が書いた記事を表示できます。
販売者数の増加とデータの増加により、サーバーのパフォーマンスは再びピークに達しました。注文は注文システムによるものであるため、正午12時の注文者の数はサーバーアーキテクチャでクレイジーなテストを受けています。注文テーブルは、今日の注文テーブルと履歴注文テーブルに分かれています。データベースとCPUは最初は解放されましたが、正午の過剰なデータと大量の同時クエリにより、CPUとメモリは依然として高いままなので、この記事では、結局、私は、頻繁に使用されるメニュー、メニューリスト、および販売者情報など、頻繁に更新されない情報ストレージ値のRedisキャッシュを正午に保存して、サーバーを軽減できるかどうかを確認することにしました。
規約に従って前後にパフォーマンスチャートを表示する
まず、テスト1コア2Gサーバーでストレステストを行います
最初はデータベースに行くことです
同時実行性が20前後の場合、大きな領域の異常が発生し、応答が遅く、インターフェースがデータを返すのが非常に遅いことがわかります
最後に、データベースデータが比較的大きい場合、同時実行クエリが遅くなり、インターフェイスの応答が特に遅くなることがわかります。100の同時漸増テストでは、同時実行数が多いほど、応答が多くなります。遅く、正午に注文するときと同じように、多数の人が同時にQRコードをスキャンしますが、応答が遅いため、データはページの回転を取得できず、エクスペリエンスに大きな影響を与えます
以下は、Redisを使用したインターフェイスのパフォーマンステストです。
Redisキャッシュが使用された後、データベースインターフェースが読み取られるたびにインターフェース応答データが読み取られ、成功率が1.59％から99.55％に増加していることがわかります。
最後に、サーバーのRedis図
次の問題は、.net MVCプロジェクトにRedisキャッシュを追加する方法の説明に焦点を当てています
