昨晚在做壓力測試的時候, 同步查詢經過了4億次的調用沒有發現問題.. 平均每秒5000次查詢請求.
但是在異步查詢時, 發現了一個奇怪的現象, 數據庫鏈接buf很快就處於阻塞狀態... 導致請求都堆積在緩衝裏... 很快數據庫就會拋出一個斷言錯誤... : [conn25] Assertion: 10334:Invalid BSONObj size: 0 (0x00000000) first element: est.user: ?type=116
0x55ece9 0x4ede7e 0x5396d8 0x75ca6b 0x75218b 0x757938 0x8a3b3e 0x8b6a40 0x7fd6110e09ca 0x7fd61068f70d
./mongod(_ZN5mongo11msgassertedEiPKc+0x129) [0x55ece9]
./mongod(_ZNK5mongo7BSONObj14_assertInvalidEv+0x46e) [0x4ede7e]
./mongod(_ZN5mongo9DbMessage9nextJsObjEv+0x148) [0x5396d8]
./mongod(_ZN5mongo12QueryMessageC1ERNS_9DbMessageE+0xbb) [0x75ca6b]
./mongod() [0x75218b]
./mongod(_ZN5mongo16assembleResponseERNS_7MessageERNS_10DbResponseERKNS_8SockAddrE+0x5b8) [0x757938]
./mongod(_ZN5mongo10connThreadEPNS_13MessagingPortE+0x21e) [0x8a3b3e]
./mongod(thread_proxy+0x80) [0x8b6a40]
/lib/libpthread.so.0(+0x69ca) [0x7fd6110e09ca]
/lib/libc.so.6(clone+0x6d) [0x7fd61068f70d]
Sat Apr 9 14:02:00 [conn25] AssertionException in connThread, closing client connection
Sat Apr 9 14:02:00 [conn25] Invalid BSONObj size: 0 (0x00000000) first element: est.user: ?type=116
Sat Apr 9 14:02:01 [conn24] end connection 127.0.0.1:49719
看錯誤報告, 似乎是某個請求的bson對象長度爲0, 於是我在發送請求前也斷言查看, 是否有bson對象爲NULL就被髮送出去... 不過遺憾的是, 並沒有收穫... , 不過至少有一個問題可以說明, 當連接上請求數量不多時是沒問題的... 所以, 打算增加幾條鏈接用於異步查詢使用 :)
補: 經查證, 服務器引擎發生波動的原因是因爲每條連接採用公用buff提取數據,每次循環讀取完整個buff, 這樣就帶來了一個問題, socket buff內存放的協議數量並非一致, buff內可容納用戶協議數量通常要比數據庫協議多得多, 這就導致了發送數據庫請求和響應數據庫的能力不平衡, 響應能力遠小於發送能力, 服務器會在一段時間之後負載過高... 以至於對buff的控制能力下降, 最終無法控制... 只能切斷連接...
這並不是我想看到的, 所以, 打算接下來增加網絡層對處理協議數量方面的負載控制 :)