對於併發這個話題已經討論很多，特別是在TCP大量聯接的成功案例很多。這裡不例舉，少說幾W多則上10W都有。

     但是作為UDP可靠傳輸協議來說，每個事務處理都需要我們的CPU完成，而且我們要維護心跳，保證條條連線能正常收發，不讓洞給關掉了，使聯接斷開。所以UDP的多條連線併發顯得格外的重要了。因為要利用UDX的實時性，高吞吐量，必須達到可用的目的。否則傳輸效能再高，也沒有什麼太大的應用空間。比如在視訊監控的流媒體伺服器處理上，這種高併發顯得就非常重要。而如果沒有併發，則只能用在點對點之間傳輸音視訊或檔案，不能大規模的替換TCP的一般場景。

      UDX的傳輸的優勢，包括實時性，吞吐量，跨平臺，這些是犧牲了大量的CPU處理時間換來的，為了能快速的回發ACK及OnTimer回撥，所以必須需要精確定時器。

為此UDX目前採用了多媒體定時器，及多執行緒，並沒有使用IOCP,EPOLL,主要是考慮跨平臺的簡單特性，使用上輕量級。可以定製，內部工作執行緒數量。

但是精確定時器的存在，比如，50MS我們需要輪詢一下，一條連線的訊息通道和資料通道。1秒的時候，一條連線要處理 20 * 2 = 40次。而傳送模組是精確到1MS級別的，那麼，一條連線就是要處理接近 40*1000 = 4w次。

最近有個客戶要求3W聯接線上，並收發資料要求，為了爭取一個客戶我開始了優化過程，其實我心裡明白的很，這是不可完成的任務，因為

以前面計算來看，如果，我們現在有1.5w條連線，就是1.5w*4w次處理。這對併發處理提出了很高的要求，但是這麼大併發測試，根本沒有過，我最多測試過2000.

我開始寫測試用例，用例程式碼可以在我的網站www.goodudx.com上下載到.用這個測試用例可以在我的機器上跑4000聯接。

本以為4000聯接已經非常好了。但是現在不得不重新查詢，每一個可能柱塞併發的地方。

客戶找來一臺AMD的伺服器，2.4G主頻，24核CPU，我開始了測試，8000併發，各個CPU，佔用都很平均，就是連線量上不去。

在1.98版本之前，我測式發，較差的機器，可以併發在2000條連線，實時性不受影響，這裡還只是一條連線只發送1KB/S.

在較好的機器上可以跑到4000條，比如我的現在I7 CPU 16G記憶體的機器中，不過主要是受CPU影響，理論上還要多一點點。

在客戶LINUX64位伺服器上測試，4000能穩定收發，8000時，有部分聯接會因為得不到處理，聯接超時斷開。

回家思考，對聯接管理，論輪採用分片式鎖定，定時器採用屬性計數方式。在處理資料時採用引用計數方式，防止鎖的範圍過大。儘量併發使用各個CPU，測試一舉通過。

支援這麼多聯接以後，結合UDX的可定製，跨平臺的特性，就完全可以在移動網際網路領域，流媒體方案中及大型即時通訊產品，雲端儲存，雲端計算中充份利用，前景一片光明。

希望更多的人來觀注UDX,支援國產軟體。