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