（一）線程數量與線程池模型
參見：high-performance server design
. http://pl.atyp.us/content/tech/servers.html 頻繁的上下文切換，會導致系統性能嚴重下降，而產生過多的切換大致有兩個原因：
１）過多的線程數量。這會使系統性能呈指數級的下降。對于每連接一個線程的系統而言，這也是為什么性能會變差的原因。一個具有可伸縮性的系統，它的唯一
可行的選擇，就是限制運行線程的數量。一般而言，這個值應該小于或等于處理器的數目。（說明，在boost網絡庫asio提供的example中，有一個
關于這種實現的很好的例子）
２）所使用的線程池及事件模型。最簡單的一種模型通常是這個樣子：一個偵聽線程異步地接收請求，并在隊列中進行緩
沖。另外一組工作者線程則負責處理這些請求。這是一個不錯的模型，缺點就是每處理一個請求一般要經過兩次線程切換（加上對請求的回復）。為了避免這種缺
點，一個線程就必須具備偵聽者和工作者兩種角色，可以采用稱之謂“領導者/跟隨者”的模型。一個線程作為領導者，來進行監聽，當收到請求時，它選出一個跟
隨者線程作為新的領導者進行偵聽，自己則對請求進行處理，結束后，到跟隨者隊列中進行等待。
（二）多線程的內存池優化
普通的內存池一旦應用到多線程中，都面臨著鎖競爭的問題，在stlport所做的對于字符串性能的測試中，當使用兩個線程時，它所使用的內存池
node_allocator性能已經出現明顯的下降。所以對于多線程而言，一個線程一個內存池是一個很好的選擇。要實現這種設計，面臨的第一個問題，是
內存塊的跨線程使用問題，即一個內存塊，可能在Ａ線程中申請，但可能在Ｂ線程中釋放。
在ＧＣＣ的ＳＴＬ實現libstdc++中，有一個多線程內存池的實現(mt_allocator)。它是node_allocator(現在叫pool_allocator) 的多線程版本。它還有一個優點就是所有參數都是可配置的。
它的設計思路如下：每個線程一個內存池，同時還有一個全局的內存池。每個線程可以訪問自己的內存池，同時可在鎖保護下訪問全局內存池。申請的每一個內存塊中，都有一個線程ID，以標明是從哪個線程中申請的。
申請過程：首先向所在線程申請，若本線程沒有空閑塊，則向全局內存池申請。
釋放過程：直接歸還到本線程的空閑鏈中。還有一個問題，為了防止線程內存池之間的不均衡，或者某一個線程中的空閑鏈過長，可以設置一個水位標，當超過這個水位標時，把釋放的內存直接歸還到全局內存池中。