當併發呼叫增加到1千以上（交換機端口鏡像過來的流量達150M），含多種語音編碼時（如g711A、U和g729等），錄音系統性能出現下降，如丟錄音，丟包，卡頓甚至崩潰等情況。
經過徹底改進和優化，錄音系統運行非常順暢，可以長時間穩定運行而不會丟失任何數據。
下面記錄一下改進的關鍵部分。
1、抓包改進
抓包庫使用的pcap_開頭的函數，有很多可優化的地方，如設置緩衝區大小，讀包延時（最好就不要延時）等。有些程序員懷疑循環讀取的方式是否能夠處理每秒幾百M的流量，是不是需要用pcap庫內核方式來處理？答案是不需要，完全可以不丟一個包。
2、rtp匹配，原先是讀寫鎖，改爲無鎖。
Rtp的數據包數量十分巨大，改爲無鎖後，匹配過程不需要做任何等候，大大提高效率。
1個線程專門處理sip信令消息，4個線程專門處理rtp包，如何做到無鎖？
1個線程專門處理sip信令消息，根據Call-ID生成一個個會話，存放在隊列裏。
我實現的讀寫鎖雖然效率高，但還是要用到條件變量、臨界區等操作系統的全局信號調用，必然還是有等待，最根本的解決之道是什麼鎖都不要。解決之道是：兵乓兩個索引，讀和寫分開。
3、對會話增加斷流判斷
會話如果丟失Bye消息，將吊死在內存中，錄音文件也關閉不了。
此外，如果一直收不到rtp語音流，保留會話只會無謂地佔用內存。
在信令處理線程中對每個會話進行跟蹤，如果超過6秒沒有再收到rtp包，將主動關閉會話，錄音結束，回收資源。
4、繞開IPP問題
對於g729編碼，我們採用Intel的高性能庫IPP，g729的處理部分分爲浮點庫和整型庫，一般採用浮點庫，對某些型號的CPU或服務器不定期出現問題，導致崩潰，將IPP升級到最新版本，問題依舊。改爲使用整型庫後，問題解決。
經過上述改進，系統可以進行運營級別的大容量錄音。
系統運行在64位的windows下，經過實際的大併發考驗，其性能和穩定性都堪稱強悍。