1、テスト用背景：によりビジネスニーズには、Redisの開発はcodis3.2バージョンを使用し、高可用性ソリューションのCODISを展開することを決めました。
2、コード：読み込みと書き込み、読み書きのRedisの非常に簡単な方法は、別々に測定します。
図3に示すように、基本的な構造：アプリケーションサーバ（12核48G）、単一インスタンスプロキシ（198Gコア48）、クラスタZK（48核198G）の3例、三つのグループCODISサーバ、各グループCODISサーバー、固有の構成次のような情報があります。
図4に示すように、圧力測定が開始され、見つかった、その周りに最高でTPS 1800、100同時平均応答時間が53msである場合、200の同時111msの平均応答時間、TPS実質的に一定の、約25％、CODISのアプリケーションサーバのCPU使用率とRedisのサーバーの圧力が非常に小さく、典型的なパフォーマンスのボトルネック現象で、ボトルネックを見つけるために始めました。
図5は、スレッドの情報を表示し、基本的な問題を見つけ、ボトルネックは、log4jのが原因で発生し、多くのlog4jロックを発見しました。また、マルチスレッドのこのバージョンでは、ログを書き込むので、そこに同期ロックがあり、そしてLog4jの2は、LMAXかく乱のロックフリーの非同期ログベースのシステムの新世代を使用して、バージョン1.xを使用してlog4jの、決定することができます。マルチスレッドプログラムでは、システムスループットの非同期は、時間遅延のLog4j 1.xの10倍よりも低いログ。私たちは今、使用理由log4j2を持っている理由です。ただ、憶測、それに実験。
図6は、次いで、印刷が任意のログではなく、log4jのログレベルがOFFの変更再始動します。テスト結果は、18,000 +にTPSを読み取ることができます金曜日の夜のテスト結果に、次のように2万+を書くことができます、アプリケーションサーバのボトルネック、今日は午後のテストで、TPSおそらく13,000、おそらく理由ネットワークを読みます実際にネットワークの場合における日中より夜間はるかに優れています。
概要：このテストは、基本的にはCODISの全体的なパフォーマンスを理解するために、TPS 20000は完全に需要を満たすことができ、それはのlog4j log4j2をアップグレードするための勧告を開発する、です。
PS：Redisの単一スレッドを使用して、唯一のシングルコアCPUを使用することができ、実際のテスト、RedisのCPU使用率が非常に低い、シングルコアのみ20％以上、そのRedisのパフォーマンスのボトルネックがCPU上にないので、おそらくこれもRedisのありますシングルスレッド理由。
作者：幻天行 出处：https://www.cnblogs.com/huantianxing/ 本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接。