Line protocol
Request :
[id:]<81digits>\r\n
Response:
[id:]<81digits>\r\n
[id:]NoSolution\r\n
Library or service?
- Cross process boundary, some overhead of course
- Cross Language
- Independent development
CPU-bounded stateless service
無狀態的CPU密集型的服務
Probably the easiest type for load balancing and provisioning(需要多少資源)
- CPU is the dominant resource, how many cores needed to serve the traffic
Concurrent Models（併發模型）
- 5 Single event loop (併發但沒有並行)
- 8 Single event loop with thread pool for computing
- 9 Multiple event loops
- 11 Multiple event loops with thread pool for computing
- 8/9/11 utilize multiple cores, 8/11 even for single client conn
- Different behavior when overloaded(過載時的表現不同)
- Memory Usage shots up (內存使用暴漲)
- How to monitor and protect
Load testing (負載測試)
- Local test （不通過網絡）
- Batch client （通過網絡，發給服務器，可以與第一種對比）
- Load test for maximum capacity (流水線，測試最大容量)
- Number of connection（併發連接數）
- Number of in-fly request a.k.a pipelines
- Stress testing(壓力測試)
- Free running
- Performance testing（性能測試）
- 延遲
使用fastcgi + nginx做負載均衡
延遲的計算
使用兩個環形緩衝區，記錄一段時間內的請求數和總延遲，然後就可以計算平均延遲。
注意計算延遲時，以哪裏爲開始，如果選擇不同的起始點，可能計算出來的平均延遲不一樣。
禁用Nagle算法
過載保護
當client發送大量的request而且不接收response會發生什麼？
對於使用線程池的server（非阻塞IO），處理request是異步的（asynchronous），IO線程讀取request的速度比工作線程處理速度快，導致request堆積。導致內存使用量升高。
此外，server的發送緩衝區會不斷堆積數據。
對於thread-per-connection模型的server，收發是同步的（阻塞IO），不會出現上面的問題。
可以對線程池的隊列大小進行檢查，如果太大，就返回錯誤並丟棄數據。這就解決了線程池隊列過載的問題。
可以設置發送緩衝區的高水位回調，HighWaterMarkCallback。
G：爲初始狀態。當發送緩衝區達到5MB時，進入狀態T（節流），如果發送緩衝區降低到0MB，也就是說客戶端接收完了，重新回到狀態G; 如果繼續增加到10MB，就進入狀態C，即斷開連接。
負載均衡
Connection level： 連接級別的負載均衡。
Request level：請求級別的負載均衡。
負載 均衡策略：random（隨機，要注意隨機數發生器），round robin（簡單，缺點：如果某個連接很busy，而某些連接很空閒，那麼實際上不能很好的起到負載均衡的效果）; 其他高級策略。
通過FastCGI作爲初級的負載均衡。這樣可以把一些工作責任交給成熟的web服務器，如nginx。nginx後面做負載均衡，這樣服務器處理的連接都來自內網。nginx對後端的fastcgi是長連接的，它會複用這些連接。
進一步適應生產環境
- Heartbeat 心跳 （sudoku server向客戶端發送心跳）
- Fault tolerance and failover （容錯和故障轉移）
- upgrading（升級）
通過server的web界面，停止某個server的心跳，客戶端發現此server沒有心跳了，就不會發送新的請求到此server，然後再通過此server的stat，當處理完後，即斷開連接，而muduo 的client會reconnect。這樣就實現了服務的重啓。
Monitoring 監控/報警
- Periodically grab： 9982/sudoku/stats and graph with rrdtool
Provisioning
- Decide How much resource needed and how to deploy the service (流量有多大，單個cpu的計算能力，計算出需要多少個cpu)
