日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
影響JavaNIO框架性能的因數(shù)

最近打算用kilim做一個rpc框架， kilim有自己的nio框架 而在業(yè)界有強勁的netty和mina。

所以問了一下kilim的作者，他的回答說 因為底層用的都是java nio的api，所以留給nio框架最主要的問題是這2點：

(i) 為了處理很多socket連接和優(yōu)化吞吐量，會導(dǎo)致了大量的線程切換。

Amount of thread switching done to handle n numbers of sockets and optimizing for throughput.

(ii) 有很多次的selector的中斷和調(diào)用，喚醒seletor是很費資源的操作。

所以能做的優(yōu)化有以下幾點：

1、對read writer process操作分別作輕量級的scheduler，基于actor。

2、有個trick，就是read或者write操作時候，但沒有讀滿或者寫完的情況下，并不是立即返回并再次注冊channel到selector，而是再嘗試若干次（3次），再返回并注冊到selector。在mina中也有同樣的處理。不同之處在于kilim會yield的當(dāng)前task，而mina為了避免線程切換，只是做了簡單的while循環(huán)。但目的都是減少線程切換和避免多次注冊 selector。

mina 處理代碼

 
 
 
    
  
  
  
  1. for (int i = WRITE_SPIN_COUNT; i > 0; i --)  
    2. 
  
  
  
  2. {  
    3. 
  
  
  
  3. localWrittenBytes = ch.write(buf.buf());  
    4. 
  
  
  
  4. if (localWrittenBytes != 0 || !buf.hasRemaining())  
    5. 
  
  
  
  5. {  
    6. 
  
  
  
  6. break;  
    7. 
  
  
  
  7. }  
    8. 
  
  
  
  8. } 
    9.

kilim nio的處理

 
 
 
    
  
  
  
  1. while (remaining > 0)  
    2. 
  
  
  
  2. {  
    3. 
  
  
  
  3. if (n == 0)  
    4. 
  
  
  
  4. {  
    5. 
  
  
  
  5. yieldCount++;  
    6. 
  
  
  
  6. if (yieldCount < YIELD_COUNT)  
    7. 
  
  
  
  7. {  
    8. 
  
  
  
  8. Task.yield(); // don't go back to selector yet.  
    9. 
  
  
  
  9. } else  
    10. 
  
  
  
  10. {  
    11. 
  
  
  
  11. pauseUntilWritable();  
    12. 
  
  
  
  12. yieldCount = 0;  
    13. 
  
  
  
  13. }  
    14. 
  
  
  
  14. }  
    15. 
  
  
  
  15. n = ch.write(buf);  
    16. 
  
  
  
  16. remaining -= n;  
    17. 
  
  
  
  17. } 
    18.

除了上面說的2個因素以外，還有有哪些因素會影響nio的性能？

原文如下：

I have not tested netty, but here's my experience. All NIO frameworks, Kilim included, are comparable because they use the same underlying NIO API. The difference in performance _may_ stem from the following two sources:

(i) Amount of thread switching done to handle n numbers of sockets and optimizing for throughput.

(ii) Number of times the selector is interrupted and invoked. Waking up the selector is an expensive operation.

The first one is entirely up to the user of the Kilim NIO library. A typical server request consists of one or more reads to accumulate the frame, processing the packet, and one or more writes to write a packet to the socket. One can split up this work between multiple schedulers if you wish. By default, all reading and writing is done outside of the selector's thread. Which brings me to the next point.

I have optimized the access to the selector, by avoiding using it as much as possible. If a socket read or write is unable to transfer any bytes, then the task simply yields. Other runnable tasks get a chance to run. When the task is subsequently resumed, it retries the operation. This goes on for a fixed number of times (3), and if it still fails, it sends a message to the selector thread to wake it up whenever the socket is ready. See the comments on kilim.nio.EndPoint.

Please keep us posted about your netty experiments.

原文地址：http://wangscu.iteye.com/blog/664688


本文題目：影響JavaNIO框架性能的因數(shù)
標(biāo)題來源：http://www.dlmjj.cn/article/cdiodsg.html