如何實現StackExchange.Redis性能調優

本篇文章給大家分享的是有關如何實現StackExchange.Redis性能調優，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

大家經常出現同步調用Redis超時的問題，但改成異步之后發現錯誤非常少了，但卻可能通過前后記日志之類的發現Redis命令非常慢。

PS: 以后代碼都在Windows bash中運行，StackExchange.Redis版本為1.2.6

   先快速重現問題和解決問題，大家先運行下面的代碼

 運行發現拋出StackExchange.Redis.RedisTimeoutException，為什么呢？是因為當前工作線程根本不夠用，同步等待時已經超時。具體請看源代碼

    如果將上面的ThreadPool.SetMinThreads(8, 8)改成ThreadPool.SetMinThreads(100, 100)呢？是不是不拋異常了呢。

    再說異步接口變慢的問題，大家先運行下面的代碼：

 最終輸出結果發現Run1和Main2是使用相同的線程吧，而Run2的ElapsedMilliseconds基本上就是在Run1的基礎上加100。

    然后再回到調用Redis代碼上

 你們發現輸出是100多還是1000多？為什么？原來是因為sdk中有一個特殊的設置，要保護異步代碼執行的順序，然后我們在GetDatabase行之前加一個代碼connection.PreserveAsyncOrder = false;

    然后再運行一次看看結果是多少呢？通過上面再做代碼基本上可以確定異步慢是和TaskCompletionSource和關系的，具體請看sdk的源代碼。

    總結上面兩點，簡單得通過SetMinThreads和connection.PreserveAsyncOrder = false可以解決絕大部分問題，但更多其他深層次的問題怎么發現呢？

    下面就要介紹StackExchange.Redis兩個神器ConnectionCounters和IProfiler 

1. 通過connection.GetCounters().Interactive獲得的對象之后其中有三個屬性非常有用

1. 每個屬性表示當前redis連接的待完成的命令當前所處的狀態。通過字面意思就可以知道PendingUnsentItems表示已經進行待發送隊列還未發送出去的命令；SentItemsAwaitingResponse表示已經發送出去但還沒有收到響應結果的命令；ResponsesAwaitingAsyncCompletion則表示已經收到響應的命令，但還沒有調用TaskCompletionSource<T>().TrySetResult()的命令。
   其中PendingUnsentItems和SentItemsAwaitingResponse過大的原因基本上是因為網絡阻塞了，你需要檢查一下網絡帶寬或者redis的value是否很大。
   ResponsesAwaitingAsyncCompletion則是因為await之后的代碼，如上面示例中的代碼，線程占用了很長的同步時間，需要優化代碼和將PreserveAsyncOrder設置為false。

2. ConnectionCounters分析的是一個線程的瞬時狀態，而IProfiler則可以跟蹤一個請求總共執行了多少的redis命令以及他們分別使用了多長時間，具體細節請大家寫代碼體驗。參考文檔

    發現問題就需要解決問題，也就需要深層次得去學習才能解決問題。我不喜歡寫文章，但發現最近有好幾篇說redis超時的問題，最終我還是想把自己的踩坑的心得分享給大家。

    這在里說一個好消息，那就是StackExchange.Redis 2.0已經從重構了異步隊列，使用管道方式解決異步慢的問題

以上就是如何實現StackExchange.Redis性能調優，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。