系统性能

在性能方面，结果很大程度上取决于我们的硬件情况，以及我们给虚拟机的 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 服务器实例以及在我们的扩展尝试中发现下一个有趣的挑战。