2. 程式人生 > >spring websocket效能調優

spring websocket效能調優

阿新 • • 發佈：2019-02-10

由於之前的排版較混亂，現重新整理髮布

TProfiler工具

TProfiler是一個可以在生產環境長期使用的效能分析工具。它同時支援剖析和取樣兩種方式,記錄方法執行的時間和次數,生成方法熱點、物件建立熱點、執行緒狀態分析等資料，為查詢系統性能瓶頸提供資料支援。

TProfiler在JVM啟動時把時間採集程式注入到位元組碼中，整個過程無需修改應用原始碼.執行時會把資料寫到日誌檔案，一般情況下每小時輸出的日誌小於50M。

業界同類開源產品都不是針對大型Web應用設計的,對效能消耗較大不能長期使，TProfiler解決了這個問題。目前TProfiler已應用於淘寶的核心Java前端系統。

定位效能瓶頸

線上客服觸屏版使用了websocket，下圖是websocket訊息傳送的流程圖
(檢視原圖)

spring websocket傳送訊息時序圖

根據業務流程，選取關鍵程式碼對其進行跟蹤取樣，在使用Tprofiler時需要設定profiler.properties，部分資訊如下，其中includePackageStartsWith是指定哪些包需要受到監控。

includePackageStartsWith = org.springframework.messaging.simp.broker;org.springframework.messaging.support;com.alibaba.dubbo.rpc.proxy;net.dwade.livechat.dubbo.service;net.dwade.livechat.touch.client.controller.stomp
 

excludePackageStartsWith = com.taobao.sketch;org.apache;com.taobao

在 jvm 啟動引數中新增-javaagent:/path/tprofiler.jar -Dprofile.properties=/path/profile.properties，然後重啟應用。

Tprofiler實踐

需要檢視Tprofiler的資料，需要先執行flushMethod操作，將記憶體中的資料寫入日誌檔案中，其中50001是Tprofiler的埠，由profiler.properties指定：

java -cp /dwade/tomcat/tomcat_touch_test/bin/TProfiler/tprofiler-1.0
 
.1.jar com.taobao.profile.client.TProfilerClient 10.112.172.125 50001

然後對執行緒和方法呼叫進行統計，其中tsampler.log是資料樣本，stat-method.log、stat-thread.log是統計輸出檔案。

java -cp /dwade/tomcat/tomcat_touch_test/bin/TProfiler/tprofiler-1.0.1.jar com.taobao.profile.analysis.SamplerLogAnalysis tsampler.log stat-method.log stat-thread.log

再對熱點方法和物件進行統計，其中tprofiler.log、tmethod.log是資料樣本，top-method.log、top-object.log是統計輸出檔案。

java -cp /dwade/tomcat/tomcat_touch_test/bin/TProfiler/tprofiler-1.0.1.jar com.taobao.profile.analysis.ProfilerLogAnalysis tprofiler.log tmethod.log top-method.log top-object.log

最後得到stat-method.log、stat-thread.log、top-method.log、top-object.log

TProfiler資料分析

執行緒資料分析

檢視stat-thread.log，可以得到執行緒的狀態統計資料，比如哪些執行緒經常出現阻塞，哪些執行緒比較繁忙、哪些執行緒比較空閒等。下面是部分資料：

3562    New I/O client worker #1-19 RUNNABLE    6187
3196    LiveChat-WebSocketSessionManagerThread-7    WAITING 6187
21219   clientInboundChannel-2728   TIMED_WAITING   38
……
23458   clientInboundChannel-2769   BLOCKED 32
……

由上述資料可知，clientInboundChannel-*執行緒經常出現阻塞，再結合tsampler.log中的執行緒棧資訊，或者使用jstack命令，很快就可以找到該執行緒阻塞的原因。如下圖所示，在DefaultSubscriptionRegistry.java的第269行出現阻塞：

spring執行緒頻繁阻塞

在getSubscriptions方法中，如果result為null，則出現synchronized鎖，因為在accessCache中獲取不到資料，為什麼呢？因為使用的updateCache的value是LinkedMultiValueMap，如果當前size大於cacheLimit，則將最少訪問的資料刪除。程式碼如下所示：

private class DestinationCache {

    /** Map from destination -> <sessionId, subscriptionId> for fast look-ups */
    private final Map<String, LinkedMultiValueMap<String, String>> accessCache =
            new ConcurrentHashMap<String, LinkedMultiValueMap<String, String>>(DEFAULT_CACHE_LIMIT);

    /** Map from destination -> <sessionId, subscriptionId> with locking */
    @SuppressWarnings("serial")
    private final Map<String, LinkedMultiValueMap<String, String>> updateCache =
            new LinkedHashMap<String, LinkedMultiValueMap<String, String>>(DEFAULT_CACHE_LIMIT, 0.75f, true) {
                @Override
                protected boolean removeEldestEntry(Map.Entry<String, LinkedMultiValueMap<String, String>> eldest) {
                    if (size() > getCacheLimit()) {
                        accessCache.remove(eldest.getKey());
                        return true;
                    }
                    else {
                        return false;
                    }
                }
            };


    public LinkedMultiValueMap<String, String> getSubscriptions(String destination, Message<?> message) {
        LinkedMultiValueMap<String, String> result = this.accessCache.get(destination);
        if (result == null) {
            synchronized (this.updateCache) {
                result = new LinkedMultiValueMap<String, String>();
                for (SessionSubscriptionInfo info : subscriptionRegistry.getAllSubscriptions()) {
                    for (String destinationPattern : info.getDestinations()) {
                        if (getPathMatcher().match(destinationPattern, destination)) {
                            for (Subscription subscription : info.getSubscriptions(destinationPattern)) {
                                result.add(info.sessionId, subscription.getId());
                            }
                        }
                    }
                }
                if (!result.isEmpty()) {
                    this.updateCache.put(destination, result.deepCopy());
                    this.accessCache.put(destination, result);
                }
            }
        }
        return result;
    }

    // other code......
}

熱點方法分析

檢視stat-method.log，可以看到在取樣期間目標方法被呼叫的次數，主要是關注哪些方法用的較多，下面是部分資料：

org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) 77921
org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)    64885
org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:44)   64885
org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:163)    64861
org.jboss.netty.channel.socket.nio.SelectorUtil.select(SelectorUtil.java:38)    64861
org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:32)    50518
org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:104)   50518
org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:86)    26948
org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:32)    26948

top方法資料分析

檢視top-method.log，可以看到目標方法在取樣期間的呼叫總時長、呼叫次數、平均耗時，下面是部分資料：

net/dwade/livechat/cache/ClientCache:getClientBySessionId:111   120647  9   1051500
net/dwade/livechat/cache/ChatSessionCache:getSessionById:45 105245  9   991919
net/dwade/livechat/cache/MessageCache:saveMessage:122   39860   22  871732
net/dwade/livechat/cache/MessageCache:getMessageById:64 36666   16  596621
net/dwade/livechat/cache/ChatRequestCache:getChatRequest:128    85844   6   477680

整理後的資料如下：

touch-client應用
touch熱點方法

dubbo應用
dubbo熱點方法

效能調優

關於tomcat等中介軟體的優化，這裡不再重複，請另行參考相關的帖子。

減少執行緒BLOCKED

線上程資料分析章節中，我們分析了spring websocket的高併發場景下的執行緒阻塞問題。專案中，我們使用了spring預設的訊息代理，在SimpleBrokerMessageHandler中有一個致命的弱點，就是使用了DefaultSubscriptionRegistry，而在這個裡面又使用了DestinationCache，這是一個基於LinkedHashMap實現的LRU快取策略，如果快取大小超過了cacheLimit值，則會去將原有舊的資料清理掉，並且再次讀取的時候仍然會去讀取所有的訂閱地址直到找到符合條件的，涉及到寫的部分，都加了synchronized重量級鎖，所以在壓測的過程中這一塊的執行緒BLOCK也是相對較頻繁的，程式的併發效能下降。目前，專案中還未使用訊息中介軟體，後續如果接入訊息中介軟體，對應用系統的效能將會有很大提高。

有以下3種優化方案：
1. 增大cacheLimit值，擴大快取資料量，減少頻繁加鎖；
2. 使用spring的BeanPostProcessor，改變SimpleBrokerMessageHandler的subscriptionRegistry實現類，這個方案難度比較大而且還有一定的風險，需要經過嚴格的測試；
3. 使用訊息中介軟體，spring會將訂閱操作交給訊息中介軟體處理，這樣便可以避免這個問題。

dubbo程式碼優化

dubbo日誌輸出

因為dubbo預設使用的log4j日誌實現，但是專案裡面使用的是logback，導致dubbo框架內部的日誌無法輸出（包括ERROR日誌），不方便後續定位問題，以下日誌是非常重要的：
1. com.alibaba.dubbo.rpc.RpcException: Invoke remote method timeout
2. c.a.d.c.t.s.AbortPolicyWithReport - [DUBBO] Thread pool is EXHAUSTED!
解決辦法：在tomcat的啟動指令碼中加下以下jvm引數：-Ddubbo.application.logger=slf4j

cache優化

在top方法資料分析裡面，我們得到了dubbo服務的方法執行耗時的統計資料：

MessageCache.getUnreadMessages()、ChatRequestCache.getChatRequest()、ChatSessionCache.getSessionById()等，這些方法有一個共同點就是大量使用了hget方法，其中ChatRequestCache.getChatRequest()使用了20+次hget呼叫reids取值，部分程式碼如下所示：

@Override
public ChatRequest getChatRequest(String requestId){

    String key = CacheConstants.ChatRequestCacheKey.PREFIX_CHAT_REQUEST+requestId;

    if(cache.exists(key)){

        ChatRequest chatRequest = new ChatRequest();
        chatRequest.setId(requestId);
        chatRequest.setClientId(cache.hget(key,"clientId"));
        chatRequest.setFromUserId(cache.hget(key,"fromUserId") );
        chatRequest.setToUserId(cache.hget(key,"toUserId") );
        String creationTime = cache.hget(key,"creationTime");

        if(!StringUtils.isEmpty(creationTime)){
          chatRequest.setCreationTime(DateUtil.str2Date(creationTime,DateUtil.YYYYMMDDHHMMSSSSS));
        }

        chatRequest.setWorkgroupId(cache.hget(key,"workgroupId"));
        String endTime = cache.hget(key,"endTime");
        if(!StringUtils.isEmpty(endTime)){
          chatRequest.setEndTime(DateUtil.str2Date(endTime,DateUtil.YYYYMMDDHHMMSSSSS ));
        }

        // 此處省略10行hget程式碼......

        return chatRequest;
    }

    return null;
}

因為會涉及多次資料傳輸，所以這個方法的效能較差。而JedisCluster中提供了hmset、hmget的api，如下圖所示。但是考慮到hmset在併發情況下會有執行緒安全問題，hset方法可以先不改造，並且目前是讀多寫少的場景。也就是說，將多個hget方法改造成一個hmget，一次性獲取多個欄位值，從而提升查詢效能。

JVM調優

為了提高系統的吞吐量，減少GC停頓時間，採用並行回收機制，同時為了減輕老年代GC壓力，將更多的物件預留在新生代，設定了較大的新生代大小，並且提高了新生代觸發GC的域值。

MEM_ARGS="-server -Xmx3550m -Xms3550m -Xmn2g -XX:PermSize=64m -XX:MaxPermSize=128m -XX:TargetSurvivorRatio=80 -XX:+UseParNewGC -XX:ParallelGCThreads=16 -XX:+UseConcMarkSweepGC"
JAVA_OPTS="-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dwade/livechat/log/jvm/touch-test.dump -Ddubbo.application.logger=slf4j $JAVA_OPTS $MEM_ARGS"

可以使用監控工具對主機資源進行監控，也可以使用常用的一些命令，比如top。另外還需要對GC活動進行監控，使用jstat –gcutil命令可以粗粒度地瞭解GC活動，也可以使用VisualVM進行視覺化監控。

參考資料:

相關推薦

spring websocket效能調優

由於之前的排版較混亂，現重新整理髮布 TProfiler工具 TProfiler是一個可以在生產環境長期使用的效能分析工具。它同時支援剖析和取樣兩種方式,記錄方法執行的時間和次數,生成方法熱點、物件建立熱點、執行緒狀態分析等資料，為查詢系統性能瓶頸提供資

Spring Cloud效能調優

Spring Cloud整合了各種元件，每個元件往往還有各種引數，並且不同spring cloud版本引數可能不同。本文來詳細探討Spring Cloud各元件的調優引數。歡迎聯絡我的QQ：59753374 或微信：jawfneo，補充或者勘誤，一起總結出最全、最實用的調

spring非同步請求action以及預設配置坑爹的效能以及對應效能調優

前言 非同步請求----客戶端一旦發起請求，伺服器立刻將請求丟到其他執行緒處理，而當前的接收執行緒就能閒下來繼續接收客戶端請求了，這個看起來效能槓槓的，這篇文章就來入坑非同步請求。 spring非同步請求的配置 預設配置下的非同步請求效能表現 進行這個操作前

Spring Cloud Feign 總結問題，注意點，效能調優，切換okhttp3

### Feign常見問題總結 **FeignClient介面如使用`@PathVariable` ，必須指定value屬性** ```java //在一些早期版本中， @PathVariable("id") 中的 "id" ，也就是value屬性，必須指定，不能省略。 @FeignClient("micro

1.效能調優概覽

介紹 Optimization Overview 優化概述 Optimizing SQL Statements 優化SQL語句 Optimization and Indexes 優化和索引 Optimizing Database Structure 優化資料庫結

深入理解Java虛擬機器總結一虛擬機器效能監控工具與效能調優(三)

深入理解Java虛擬機器總結一虛擬機器效能監控工具與效能調優(三) JDK的命令列工具 JDK的視覺化工具 效能調優 JDK的命令列工具 主要有以下幾種: jps (Java Process Status Tool): 虛擬機器程序

【Big Data 每日一題】Spark開發效能調優總結

1. 分配資源調優 Spark效能調優的王道就是分配資源,即增加和分配更多的資源對效能速度的提升是顯而易見的,基本上,在一定範圍之內,增加資源與效能的提升是成正比的,當公司資源有限,能分配的資源達到頂峰之後,那麼才去考慮做其他的調優 如何分配及分配哪些資源 在生產環境中,提交spark作

nkv客戶端效能調優

此文已由作者張洪簫授權網易雲社群釋出。 歡迎訪問網易雲社群，瞭解更多網易技術產品運營經驗。 問題描述 隨著考拉業務的增長和規模的擴大，很多的應用都開始重度依賴快取服務，也就是杭研的nkv。但是在使用過程中，發現服務端壓力並不是特別大的情況下，客戶端的rt卻很高，導致應用在到達一定併發的情況下，服務的質量下降的

ifeve.com 南方《JVM 效能調優實戰之：使用阿里開源工具 TProfiler 在海量業務程式碼中精確定位效能程式碼》

https://blog.csdn.net/defonds/article/details/52598018 多次拉取 JStack，發現很多執行緒處於這個狀態：    at jrockit/vm/Allocator.getNewTla(JJ)V(Native Method) 

實時計算 Flink效能調優

自動配置調優 實時計算 Flink新增自動調優功能autoconf。能夠在流作業以及上下游效能達到穩定的前提下，根據您作業的歷史執行狀況，重新分配各運算元資源和併發數，達到優化作業的目的。更多詳細說明請您參閱自動配置調優。 首次智慧調優 建立一個作業。如何建立作業請參看快速入門。 上線作業

Hadoop效能調優全面總結

一、 Hadoop概述 隨著企業要處理的資料量越來越大，MapReduce思想越來越受到重視。Hadoop是MapReduce的一個開源實現，由於其良好的擴充套件性和容錯性，已得到越來越廣泛的應用。 Hadoop實現了一個分散式檔案系統（Hadoop Distributed File Sys

eclipse效能調優的一次記錄

最近因為學習原因，eclipse中外掛越來越多，造成eclipse一次次假死，著實很影響工作效率和心情，有時正是興起，但是造成短片很令人生氣，如果eclipse卡頓或者假死，在電腦配置較不錯的情況下，不要懷疑自己的電腦，嘗試去除錯一下自己的eclipse。   找到eclipse或

nginx監控與效能調優

監控 nginx有自帶的監控模組，編譯nginx的時候,加上引數 --with-http_stub_status_module #配置指令 ./configure --prefix=/usr/local --user=nginx --group=nginx

Tomcat效能調優以及遠端管理（Tomcat manager與psi-probe監控）

tomcat優化的我用到的幾個點： 1.記憶體優化 2.執行緒優化 docs/config/http.html maxConnections acceptCount（配置的太大是沒有意義的） maxThreads minSpareThreads 最小空閒的工作

MySQL 效能調優技巧

技巧#1：確定MySQL的最大連線數 對於MySQL的最大連線數，一次最好是傳送5個請求到Web伺服器。對Web伺服器的5個請求中的一部分將用於CSS樣式表，影象和指令碼等資源。由於諸如瀏覽器快取等原因，要獲得準確的MySQL到Web伺服器的請求比率可能很困難; 要想得到一個確切的數字，就需要分

Tomcat8 效能調優

1.優化Linux核心及TCP連線 編輯系統配置檔案： vim /etc/sysctl.conf 修改內容如下： 配置 說明 fs.file-max = 655350 系統檔案描述符

JVM效能調優監控工具jps、jstack、jstat、jmap、jinfo使用

 現實企業級Java開發中，有時候我們會碰到下面這些問題： OutOfMemoryError，記憶體不足 記憶體洩露 執行緒死鎖 鎖爭用（Lock Contention） Java程序消耗CPU過高 ...... &n

Spark之效能調優總結（一）

總結一下spark的調優方案： 一、效能調優 　　1、效能上的調優主要注重一下幾點： 　　　　Excutor的數量 　　　　每個Excutor所分配的CPU的數量 　　　　每個Excutor所能分配的記憶體量 　　　　Driver端分配的記憶體數量 　　2、如何分配資源 　　　　在生產環境中，

Nginx效能調優之快取記憶體

Nginx可以快取一些檔案（一般是靜態檔案），減少Nginx與後端伺服器的IO，提高使用者訪問速度。而且當後端伺服器宕機時，Nginx伺服器能給出相應的快取檔案響應相關的使用者請求。 一 Nginx靜態快取基本配置 在tomcat的webapps目錄下建立hello.html,內容

第一章 Java效能調優概述

效能概述 看懂程式的效能 一般來說，程式的效能能通過以下幾個方面來表現： 執行速度：程式的反映是否迅速，響應時間是否足夠短 記憶體分配：記憶體分配是否合理，是否過多地消耗記憶體或者存在洩漏 啟動時間：程式從執行到可以正常處理業務需要花費多長時間 負責承受能力：當系統壓力上升時，系統的執