最近一段時間利用boost多執行緒和ace多執行緒，對exosip的效能進行了比較深入一些的測試。現將測試方法分享一下，在此拋磚引玉，希望大家也可以提供一些建議。
首先，原始的exosip只有2個執行緒，乙個做的事情很簡單，是等待事件，另外乙個執行緒非常忙，要做事務狀態的轉換，要收訊息，要解析訊息，要上報事件。
我所做的修改就是將不同的事情分開到不同的執行緒，相當於簡單地修改exosip。
修改步驟如下：
1 exosip_wait保持原來的呼叫方法，但是這個方法中有一些多餘的**暫時遮蔽（也可能是暫時不能理解）
2 將從5060埠收資料放到乙個執行緒池a中做，這樣socket就不會阻塞了。
3 將處理收到的訊息放到執行緒池b中做，訊息處理很複雜，這個執行緒池中線程的數量也是最大的。
4 將做事務狀態轉換的事全放到乙個執行緒中做，事務狀態轉換是關鍵，量也很大，狀態的轉換速度決定著exosip_wait的返回頻率。
以上是多執行緒的改造
在以上四個執行緒池的執行緒數達到48:64:128:256的時候效能達到最優，處理能力達到2500條每秒。測試的機器是我們機房的那個cvss上面安裝的虛擬機器。這個機器是4核的，如果配置再高一些，執行緒數可以再提高一些，資料也會更好。
//sufu#define default_t1 500 /* 500 ms 國標推薦 */
#define default_t1 2 /* 測試使用的值*/
//sufu #define default_t2 4000 /* 4s 國標推薦*/
#define default_t2 2 /* 測試使用的值*/
//sufu #define default_t4 5000 /* 5s國標推薦 */
#define default_t4 2 /* 測試使用的值*/
這四個數字的具體使用，可以再**中搜尋，並除錯程式去了解。
其實這幾個值並不是影響測試資料的最終原因！！！
我有乙個粗淺的解釋，osip的狀態機使用了定時機制，比如，乙個事件的處理有s1 s2 s3個狀態，服務端在將s1狀態轉換到s2狀態前，要看所定的時間到了沒有。時間沒有到，就不做狀態轉換，當然，狀態轉換是要做一些其他的工作的。
試想一下，如果s1到s2花500毫秒，s2到d3花500毫秒，那我處理乙個完整的事件就花掉了1秒，那我乙個客戶端1個執行緒1分鐘就幹60件事情，60個執行緒才做3600件事情，10臺電腦1分鐘也就做36000件事情。當然，理論上如果有30臺電腦，每台電腦上開60個執行緒，1分鐘就可以做72000件事情，但我們的目標是1分鐘要做3000*60甚至更多事情。
所以只能暫時修改一下服務端的狀態機轉換間隔，一步步地縮小，直到2ms,甚至1ms，來替代客戶端數量的不足。
改造以後，資料達到2500條每秒，激勵我們的目標還差每秒500~1000，但是我們的伺服器效能還是可以提公升的，我們的程式研究也還在初步階段（大約8個工作日），所以優化工作還是可以繼續進行的，而一旦程式優化成果，我們後面要做的sip伺服器的開發工作量就少了很多。
更多sip解決方案，視訊整體解決方案 ,gbt28181,28181
exosip鏈結問題
exosip.lib exosip.obj error lnk2019 無法解析的外部符號 osip transaction set reserved1，該符號在函式 exosip transaction init 中被引用 1 exosip.lib exosip.obj error lnk2019...
關於 迴圈 效率的問題
今天寫到迴圈邏輯，糾結於是用更少的迴圈呼叫函式還是用更少的函式，多迴圈兩次。於是做了個實驗，發現基於c的lua，函式呼叫的代價果然很高。local tb local max 10000000 for i 1,max do tb i i endfunction check i,max if tb i ...
關於for while的效率問題
首先比較for與while的效率問題必須保證迴圈次數一致 下面簡單的分析for與while的效率問題就從最簡單的無限迴圈開始，其餘相同 for while 1 這兩句都實現了無限迴圈的功能，使用gcc編譯成彙編 為 for file for.c text globl main type main,f...