搜集端程序相当于客户端，在HTTP/1.0中，即使客户端希望在同一次会话中从同一服务器传输更多的HTML页面，该TCP连接也会被终止，每一个新的请求需要建立另一个TCP连接，这造成了HTTP服务器的负担。

在HTTP 1.1版中，提供对持续TCP连接的支持，可以参看RFC2068 Hypertext Transfer Protocol — HTTP/1.1。这样改变一下可节省Web服务器资源，而且可以节省网络可使用的带宽。此外，由于避免了每次请求都重新建立连接的开支，使用一个持续的连接比HTTP /1.0的实现具有更高的操作效率。在TSE中使用的是HTTP/1.1的请求方式，注意不是简单的更换HTTP/1.0这个字串为HTTP/1.1，而是需要保留上次已经建立的连接，如果该连接没有失效，则本次继续使用。

通常情况下局域网的延迟（latency）在1-10ms，带宽（bandwidth）为10-1000Mbps，Internet的延迟在100-500ms，带宽为0.010-2 Mbps。所以针对搜索引擎应用的搜集程序通常是在同一个局域网内的多台机器，每个机器多个进程并发的工作。这样一方面可以利用局域网的高带宽，低延时，各节点充分交流数据，另一方面采用多进程并发方式降低Internet高延迟的副作用。

因为局域网的利用率几乎接近1，而Internet因为有路由和拥塞控制等额外要求利用率不高，所以局域网与Internet的连接是至关重要的。因此需要同时启动多个gatherer并发的创建多个TCP连接，并发的下载网页。这种方式加快了Web信息的搜集，但是要避免多个gatherer重复的收集网页（在下一小节中具体介绍解决方法），还要避免由于同一时间内与同一服务器连接过多而给服务器端造成的严重性能问题。

究竟应该有多少个节点并行搜集网页，每个节点启动多少个gatherer？下面逐步分析得到。先给出理论值，然后给出经验值，最后给出单节点的搜集效率。

计算理论值

天网2002年1月统计纯文本网页平均大小为13KB（下文中不特殊说明的网页均指纯文本网页）。

在连接速率为100Mbps快速以太网络上（以太网的MTU（Maximum Transfer Unix）是1500字节），假设线路的最大利用率是100%，则最多允许每秒传输（1.0e+8b/s）/ （1500B×8b/B）≈ 8333个数据帧，也即每秒传输8333个网页。

如果局域网与Internet的连接为100Mbs，Internet带宽利用率低于 50%，则每秒传输的网页数目平均不到4000个。

如果搜集系统由n个节点组成，单个节点启动的gatherer数目应该低于4000/n。

经验值

在实际的分布式并行工作的搜集节点中，还要考虑CPU和磁盘的使用率问题，通常CPU使用率不应该超过50%，磁盘的使用率不应该超过80%，否则机器会响应很慢，影响程序的正常运行。在天网的实际系统中局域网是100Mbps的以太网，假设局域网与Internet的连接为100Mbps（这个数据目前不能得到，是我们的估计），启动的gatherer数目少于1000个。这个数目的gatherer对于上亿级的天网搜索引擎是足够的。

单节点的搜集效率

以太网数据帧的物理特性是其长度必须在46~1500字节之间。说明在一个网络往返时间RTT为200ms的广域网中，服务器处理时间SPT为100ms，那么TCP上的事务时间就大约500ms（2×RTT+SPT）。

网页的发送是分成一系列帧进行的，则发送1个网页的最少时间是(13KB/1500B) × 500ms ≈4s。如果系统处于满负荷运转，单个节点启动100个gatherer程序，则每个节点每天应该能够搜集（24×60×60s/4s）× 100pages = 2,160,000个网页。考虑到gatherer实际运行中可能存在超时，搜集的网页失效等原因，每个节点的搜集效率小于2,160,000个网页/天。