基于Scrapy构建数据采集系统-资源Scrapy性能模型Scrapy性能模型.docxVIP

Scrapy性能模型 PAGE 0 [文档标题 Scrapy性能模型 一、Scrapy性能模型 首先我们看下Scrapy的性能模型（图一）。 图一 Scrapy由下面几部分组成： 调度器：所有的Request对象都在这里排队，直到下载器已经准备好了 来处理它。Reuqest主要由URL组成，所以比较紧凑，也就是说即使有很多Request也不会导致性能问题，并且还可以使下载器一直处于满负荷工作状态。 节流器（throttler）：这是一个安全阀门，它从scraper获得反馈，如果正在处理的响应加起来超过了5MB，它就会阻止Request对象进入到下载器中。这可能会导致性能波动。 下载器：对于性能方面，这是Scrapy最值得关注的一个组件。它对于可以同时并发处理的Request对象的数目有着复杂的限制。它的延迟（亦即管道的长度）等于远程服务器响应的时间加上网络/操作系统和Python/Twisted的延迟。我们可以调整并发的Request对象的数目，但是没法控制延迟，所以下载器的容量由CONCURRENT_REQUESTS*设置项来控制。 爬虫：这是scraper的一部分，它从返回的响应中提取Item和接下来的Request对象。一般情况下，只要按照规则来写这部分的代码，爬虫就不会成为性能瓶颈。 Item pipelines：这是scraper的第二个部分。爬虫对应于每个Request会产生许多个Item，不过只有CONCURRENT_ITEMS个会同时进行并发处理。这点是很重要的，因为，例如，你在pipeline中进行数据库操作，或许就会无意识地对你的数据库进行了洪泛攻击，因为默认值（100）就已经太高了 。 爬虫和pipeline都有异步的代码，并且会导致大部分的延迟，但是即使这样，它们也不应该被当做瓶颈。极少数情况下，爬虫和pipeline会做一些复杂的处理，此时的瓶颈会是我们服务器的CPU。