perl - TCP，HTTP和多线程Sweet Sp

Question

我正在尝试了解所获得的性能数字以及如何确定最佳线程数。

有关我的结果，请参见本文的底部

我在perl中编写了一个实验性的多线程Web客户端，该客户端下载页面，获取每个图像标签的源，然后下载图像-丢弃数据。

它使用无阻塞连接，每个文件的初始超时为10秒，在每次超时并重试后增加一倍。它还缓存IP地址，因此每个线程只需要执行一次DNS查找。

通过从http://hubblesite.org/gallery/album/entire/npp/all/hires/true/进行的2.5Mbit连接，在1316个文件中下载的数据总量为2271122字节。缩略图由一家公司托管，该公司声称专门针对高带宽应用程序提供低延迟。

挂墙时间是:

1 Thread takes 4:48 -- 0 timeouts
2 Threads takes 2:38 -- 0 timeouts
5 Threads takes 2:22 -- 20 timeouts
10 Threads take 2:27 -- 40 timeouts
50 Threads take 2:27 -- 170 timeouts

在最坏的情况下(50个线程)，客户端消耗不到2秒的CPU时间。

平均文件大小1.7k
平均rtt 100毫秒(通过ping测量)
平均cli cpu/img 1毫秒

最快的平均下载速度是5个线程，整体速度约为15 KB/秒。

服务器实际上确实具有非常低的延迟，因为获取每个图像仅花费218毫秒，这意味着服务器处理每个请求平均仅花费18毫秒:

0 cli发送syn
50 srv rcvs syn
50个srv发送syn + ack
建立了100个cli conn/cli发送get
150 srv recv的
168 srv读取文件，发送数据，调用关闭
218个cli recv HTTP header + 2个段中的完整文件MSS == 1448

我看到每个文件的平均下载速度较低，这是因为文件较小，并且连接设置的每个文件的成本相对较高。

我不明白的是为什么我看不到超过2个线程的性能几乎没有改善。服务器似乎足够快，但是已经开始以5个线程超时。

无论是5个线程还是50个线程，超时连接似乎都是在大约900-1000个成功连接之后开始的，我认为这可能是服务器上的某种限制阈值，但我希望10个线程仍然比2个线程快得多。

我在这里想念什么吗？

EDIT-1

为了比较起见，我安装了DownThemAll Firefox扩展并使用它下载了图像。我将其设置为4个同时连接，超时时间为10秒。 DTM花了大约3分钟的时间下载了所有文件，然后将它们写入磁盘，并且在连接了大约900个连接后，DTM也开始出现超时。

我将运行tcpdump尝试以更好地了解tcp协议(protocol)级别的情况。

我还清除了Firefox的缓存并点击重新加载。 40秒重新加载页面和所有图像。这似乎太快了-也许Firefox将它们保存在未清除的内存缓存中？因此，我打开了Opera，这也花了大约40秒钟。我认为它们的速度如此之快是因为它们必须使用HTTP/1.1流水线？

答案是!？

因此，在进行了一些测试并编写了代码以通过管道重用套接字后，我发现了一些有趣的信息。

当以5个线程运行时，非流水线版本将在77秒内检索到前1026张图像，但又需要65秒才能检索剩余的290张图像。这几乎证实了 MattH's理论，该理论关于我的客户端受到 SYN FLOOD事件的攻击，该事件导致服务器在短时间内停止响应我的连接尝试。但是，这只是问题的一部分，因为5线程获取1026张图像的77秒仍然很慢；如果您删除了 SYN FLOOD问题，则仍然需要大约99秒钟来检索所有文件。因此，基于一些研究和一些 tcpdump，似乎问题的另一部分是延迟和连接设置开销。

这是我们回到寻找“最佳点”或最佳线程数的问题的地方。我修改了客户端以实现HTTP/1.1管道传输，发现这种情况下的最佳线程数在15到20之间。例如:

1 Thread takes 2:37 -- 0 timeouts
2 Threads takes 1:22 -- 0 timeouts
5 Threads takes 0:34 -- 0 timeouts
10 Threads take 0:20 -- 0 timeouts
11 Threads take 0:19 -- 0 timeouts
15 Threads take 0:16 -- 0 timeouts

有四个因素
影响这一点；延迟/rtt，最大端到端带宽，recv缓冲区大小
以及正在下载的图像文件的大小。 See this site for adiscussion on how receive buffer size and RTT latency affect availablebandwidth。

除上述之外，平均文件大小会影响每个连接的最大大小
传输速率。每次您发出GET请求时，都会在
您的传输管道，即连接RTT的大小。例如，如果
您的最大可能传输速率(recb buff大小/RTT)为2.5Mbit，
您的RTT为100毫秒，那么每个GET请求都会在您的应用中产生至少32kB的间隙
管道。对于320kB的较大平均图像大小，这需要10％的开销
每个文件，有效地将您的可用带宽减少到2.25Mbit。然而，
对于3.2kB的较小平均文件大小，开销跃升至1000％，
可用带宽降低到232 kbit/秒-大约29kB。

因此，要找到最佳线程数:

Gap Size = MPTR * RTT
MPTR / (MPTR / Gap Size + AVG file size) * AVG file size)

对于我上面的情况，这为我提供了11个线程的最佳线程数，这与我的实际结果非常接近。

如果实际的连接速度比理论上的MPTR慢，那么它将
应该在计算中使用。

Answer 1

请纠正我，此摘要不正确:

您的multi-threaded客户端将启动一个连接到服务器的线程，并仅发出一个HTTP GET，然后该线程关闭。

当您说1、2、5、10、50个线程时，您仅指的是允许多少个并发线程，每个线程本身仅处理一个请求。

您的客户端需要2到5分钟才能下载超过1000张图片

Firefox和Opera将在40秒内下载等效数据集

我建议服务器通过Web服务器守护程序本身，服务器本地防火墙或最有可能的专用防火墙来限制HTTP连接的速率。

实际上，您通过不重复使用HTTP连接进行多个请求实际上是在滥用Web服务，并且您遇到的超时是因为 SYN FLOOD被限制。

Firefox和Opera可能使用4到8个连接来下载所有文件。

如果重新设计代码以重新使用连接，则应该获得类似的性能。