Question

在性能方面，结果很大程度上取决于我们的硬件情况，以及我们给虚拟机的CPU数量和内存大小。在实际部署中，我们可以获得水平的伸缩性，可以让我们以服务器允许的最快速度运行爬取。

对于给定设置情况下的理论最大值是：3个服务器 · 4个处理器/服务器 · 16个并发请求 · 4个页面/秒（通过页面下载延迟定义）= 768个页面/秒。

实践时，在Macbook Pro中使用分配了4GB内存以及8核CPU的VirtualBox虚拟机，我可以在2分40秒的时间内获取50,000个URL，也就是大约315个页面/秒。在拥有2个vCPU和8GB内存的Amazon EC2 m4.large实例中，由于有限的CPU能力，花费了6分12秒的时间，即134个页面/秒。在拥有16个vCPU和64GB内存的Amazon EC2 m4.4xlarge实例中，爬取完成时间是1分44秒，即480个页面/秒。在同一台机器中，我将Scrapyd的实例数量加倍，即增加到6个（只需编辑Vagrantfile、scrapy.cfg以及settings.py），此时爬虫完成时间为1分15秒，即其速度为667个页面/秒。在最后一种情况下，我们的Web服务器似乎遇到了瓶颈（在实际中意味着中断）。

我们得到的性能与理论最大值之间的距离是合理的。有很多小的延迟在我们的粗略计算中是没有考虑进去的。尽管我们之前声称有250ms的页面加载延迟，但是在前面的章节中可以看到该延迟实际上更大，因为至少还有Twisted和操作系统的延迟。另外，还有一些其他延迟，比如URL从开发机传输到Scrapyd服务器的时间、我们爬取的Item通过FTP传给Spark的时间以及Scrapyd发现和计划任务所花费的时间（平均2.5秒——参考Scrapyd的poll_interval设置）。此外，还有开发机以及Scrapyd爬取的启动时间没有计算进来。我将不会尝试改善这些延迟中的任何一个，除非能确定它们可以提升吞吐量。我的下一步是增加爬取的大小（比如50万个页面）、负载均衡几个Web服务器实例以及在我们的扩展尝试中发现下一个有趣的挑战。