- 論壇徽章:
- 2
|
本帖最后由 knull 于 2014-08-19 19:41 編輯
環(huán)境:A,B,C三臺(tái)機(jī)器,A,B是一般的pc機(jī)器,雙核+1Gbps;C是服務(wù)器,8核+1GBps;都是windows系統(tǒng);
測(cè)試內(nèi)容:用ACE編寫(xiě)的網(wǎng)絡(luò)測(cè)試程序,簡(jiǎn)單的客戶端、服務(wù)端;只不過(guò)發(fā)送的tcp報(bào)文比較大,每條消息80K;socket的接收、發(fā)送隊(duì)列,都設(shè)置為512K。
測(cè)試結(jié)果:A和C測(cè)試,發(fā)送10000條,耗時(shí)近80秒,即近10M每秒;對(duì)每次recv收到的大小統(tǒng)計(jì),發(fā)現(xiàn)其中大部分是1460字節(jié),占90%+;
A和B測(cè)試,發(fā)送10000條,沒(méi)統(tǒng)計(jì)耗時(shí);統(tǒng)計(jì)每次的recv的大小,發(fā)現(xiàn)其中50%是30-40K;0-10K,10-20K,20-30K各占10%左右;其余的,80-520K大約占10%。
分析:在對(duì)軟件進(jìn)行性能分析的時(shí)候,發(fā)現(xiàn)TCP通信是瓶頸,所以單獨(dú)拿出來(lái)測(cè)試了下,發(fā)現(xiàn)還是這樣子的。說(shuō)明,很可能的確是TCP造成的問(wèn)題。由于每次接收的包都不大,說(shuō)明接收端是不飽和的(如果飽和,那么緩沖有512K,完全不會(huì)recv這么小的數(shù)據(jù)包)。這是發(fā)送端,也是send整個(gè)80K數(shù)據(jù)包。是不是可能是因?yàn)閠cp發(fā)送慢造成的?另外,很明顯的就是,C作為服務(wù)器,為什么反而不如pc機(jī)B?
提問(wèn):這里,tcp通信存在瓶頸,那么可能是什么原因造成的?有沒(méi)有改進(jìn)的可能?
謝過(guò) |
|