一度zulの圧力テストを覚える

abツールを使用してspring cloudのzulを圧力テストします.私のゲートウェイはtokenの論理を検証するだけで、tokenが存在しない場合はヒントを返します.しかし,qps(ここでもtpsと理解できる)は400程度であることが分かった.しかし、広範なオープンソースコンポーネントを適用する場合、これは明らかに最適化されていない.
jconsoleを用いて観察する
jconsoleはjdkが持参したツールです.
起動時にパラメータを追加

 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false  -Dcom.sun.management.jmxremote.port=2099 -Djava.rmi.server.hostname=192.168.50.5

メモリとcpuに異常はないことが分かった.スレッドを観察すると、私の同時実行がいくらであっても、実際に実行されているスレッドは1つまたは2つであり、これは間違っていることを示しています.そこでabツールやネットワーク構成が間違っているのではないかと疑い始めました.
1、abツールをcentos 7システム本体に装着し、同時に以下の調整を行った.
(1)ulimit -SHn 65535 
(2)修正/ect/sysctl.conf

#  
net.ipv4.tcp_syncookies=0
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
net.nf_conntrack_max=100000
net.netfilter.nf_conntrack_max=100000

(3)サーバ上の/etc/sysctl.confの変更

#  
net.ipv4.tcp_syncookies=0
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1

現在qpsは1000以上に達していますが、まだ理想的ではありません.
2、jprofilerとjstackを使って新しいボトルネックを見つける
Windowsにjprofiler 9をインストールすることで、サーバにもjprofiler 9をインストールしました(バージョンは一致して、ここからダウンロードしますhttps://download.csdn.net/download/chs007chs/10930102)、これによりwindowsマシン上でインタフェースを介してサーバ上のjvmプロセスに接続することができ、ここでは圧力測定時にスレッドblockedがあることを発見しました.そこでjstackツールdumpでスレッドスナップショットを作成すると、logbackログがファイルに書き込まれたスレッドがブロックされていることがわかりました.
ログプロファイルを変更します.

        ${log.path}/${application.name}/info.log
        true
        
            ${log.path}/${application.name}/%d{yyyy-MM-dd}/info/info-%i.zip
            50MB
            7
            2GB
        
        
            %d{yyyy-MM-dd HH:mm:ss} [%p] [%t] %c - %m%n
        
        
            INFO
            ACCEPT
            DENY
        
    

    
        ${log.path}/${application.name}/warn.log
        true
        
            ${log.path}/${application.name}/%d{yyyy-MM-dd}/warn/warn-%i.zip
            50MB
            15
            2GB
        
        
            %d{yyyy-MM-dd HH:mm:ss} [%p] [%t] %c - %m%n
        
        
            WARN
            ACCEPT
            DENY
        
    

    
        ${log.path}/${application.name}/error.log
        true
        
            ${log.path}/${application.name}/%d{yyyy-MM-dd}/error/error-%i.zip
            50MB
            15
            2GB
        
        
            %d{yyyy-MM-dd HH:mm:ss} [%p] [%t] %c - %m%n
        
        
            ERROR
            ACCEPT
            DENY
        
    

    
        0
        512
        
    

    
        0
        512
        
    

    
        0
        512
        
    

非同期ログを使用することでスレッドがブロックされなくなり、jprofilerを使用して観察を続けたところ、CPU View->Call Treeで、私がカスタマイズしたzulFilterでfastjsonを使用してシーケンス化する場合にcpuが消費されることがわかり、カスタムzulfilterを再修正し、fastjsonの使用を減らしました.最後に、qpsは3000ぐらいで、その本は私の予想を満たしました.