版上各位先進好:
小弟我目前在設計多執行緒的伺服器上遇到效能瓶頸，
底層的Socket Server是用Boost::Asio，
單純用single io_service & multiple thread的架構處理效能還不錯，
但目前系統上都會需要封包指令是要將某個index要對應到某個session，
所以只好在accept時把index跟session存入到map中，這時就需要使用lock去做保護，
因為加了這個lock導致在一秒內如果是上萬的連線數要aceept延遲就會提高，
後面開始run的過程中因為我使用的是shared_mutex，
所以對map純讀(shared_lock)感覺效能還可以。
如果是單純讀寫分離的Queue還可以用boost::lockfree去處理，
但遇到真的架構上就需要有一個map，這種情況就不知道怎麼優化它，
想問版上的各位先進有什麼設計方向可供我參考，謝謝。

白說這問題打成英文上 stackoverflow 問應該會比較好坦白說目前可以知道的資訊有點少，也許你目前這層可以複製 N 個docker containers 去跑起來，然後最前端再擋個類似負載平衡的東西，譬如根據 index % N 的值來轉發封包給對應的container 處理這個 request。這種解法比較偏向架構解，考量將來 scalability 的話你早晚要做類似的工。如果你只打算先集中在程式解，那試試看起多個 io_context 有沒有什麼用吧。io_service 在新版 boost 已經 deprecated 了。簡單講的話目的都是先增加你程式的入口數，然後把原本因為 lock 變成瓶頸的單一大資料塊拆分成多個。

vector 存 index + session, 就不用lock ?

問題在於你為什麼會設計成一秒需要 accept 上萬次吧

int64_t你也用不完呀 實務上你抓個可以涵蓋峰值的大小配就好了 而且vector要鎖最起碼可以個別鎖呀

每一條連線有平均與最大的耗用資源量,同時估計一下response time/CPU時間,找出一臺機器的服務上限,對應的session數量一次配置完,連線對應固定的索引值就不用map了

寫個load balancer

SO_REUSEPORT https://goo.gl/4rxJfr 參考看看若非得查表可考慮使用 tbb::concurrent_unordered_map