扭曲吞吐量限制減少

Question

我正在開發一個允許在一台機器上模擬網絡的程序。 為此，我使用Twisted進行異步I / O，因為每個'連接'都有一個線程可能有點多。 （我還使用他們的NIO在Java中實現了類似的程序）。 但是，隨着我對模擬網絡規模的擴展，Twisted上的吞吐量會降低。 將其與Java實現進行比較時，對於相同的網絡大小，Java吞吐量會繼續增長。 （增長率放緩，但仍然是增長）。 例如（Python 100節點= 58MB總吞吐量，300個節點= 45MB，Java 100節點= 24 MB，300個節點= 56MB）。

我想知道是否有人有任何關於為什么會發生這種情況的建議？

我能想到的唯一原因是Java的每個'peer'都在自己的線程中運行（它包含自己的監視對等連接的選擇器）。 在python版本中，所有內容都在reactor（以及隨后的一個選擇器）中注冊。 隨着python的擴展，一個選擇器無法快速響應。 然而，這只是一個猜測，如果任何人有任何更多的具體信息，它將被appriciated。

編輯：我按照Jean-Paul Calderone的建議進行了一些測試，結果發布在imgur 。 對於那些可能想知道測試報告以下Avg吞吐量的人。 （分析是用cProfile完成的，測試運行了60秒）

Epoll Reactor：100對等：20.34 MB，200對等：18.84 MB，300對等：17.4 MB

選擇Reactor：100對等：18.86 MB，200對等：19.08 MB，300對等：16.732 MB

對報告的吞吐量似乎上下的一些事情是對main.py:48(send）的調用，但這種腐蝕並不是一個驚喜，因為這是數據發送的地方。

對於兩個反應器，套接字上的發送功能所花費的時間隨着吞吐量的減少而增加，並且隨着吞吐量的減少，對發送功能的調用次數也減少。 （也就是說：在套接字上花費的時間更多，在套接字上發送的呼叫次數更少。）例如，對於413600個呼叫，100個對等體上的epoll {方法'發送''_socket.socket'對象}為2.5秒，為5.5對於300個同行的epoll，為354300個電話。

為了嘗試回答原始問題，這些數據是否似乎指向選擇器是一個限制因素？ 在Selector中花費的時間似乎隨着對等體數量的增加而減少（如果選擇器減慢了一切，那么人們不會期望內部花費的時間會增加嗎？）還有什么可能會減慢發送的數據量？ （數據的發送只是一次又一次向reactor.calllater注冊的每個對等體的一個函數。那就是main.py:49（發送））

Answer 1

嘗試在不同的並發級別上分析應用程序，並在添加更多連接時查看哪些內容變慢。

select是一個可能的候選人; 如果您發現在添加連接時使用的時間越來越多，請嘗試使用poll或epoll reactor 。