Question

我正在使用scrapy来刮掉多个站点，Scrapyd用来运行蜘蛛。

我编写了7个蜘蛛，每个蜘蛛处理至少50个起始URL。我有大约7000个URL。每个蜘蛛的1000个URL。

当我开始在ScrapyD中放置工作时，每个作业有50个起始URL。最初所有的蜘蛛都反应良好，但突然之间他们开始工作的速度很慢。在localhost上运行它时，它可以提供高性能。

当我在localhost上运行Scrapyd时，它给了我非常高的性能。当我在Scrapyd服务器上发布作业时。请求响应时间急剧减少。

服务器上的一段时间后，每个起始URL的响应时间非常慢

设置如下所示：

BOT_NAME = 'service_scraper'

SPIDER_MODULES = ['service_scraper.spiders']
NEWSPIDER_MODULE = 'service_scraper.spiders'

CONCURRENT_REQUESTS = 30

# DOWNLOAD_DELAY = 0

CONCURRENT_REQUESTS_PER_DOMAIN = 1000


ITEM_PIPELINES = {
   'service_scraper.pipelines.MongoInsert': 300,
}

MONGO_URL="mongodb://xxxxx:yyyy"


EXTENSIONS = {'scrapy.contrib.feedexport.FeedExporter': None}


HTTPCACHE_ENABLED = True

我们尝试更改CONCURRENT_REQUESTS和CONCURRENT_REQUESTS_PER_DOMAIN，但没有任何效果。我们在AWS EC2中托管了scrapyd。

Answer 1

与所有性能测试一样，目标是找到性能瓶颈。这通常属于以下一个（或多个）：

内存：使用top来衡量内存消耗。如果消耗太多内存，它可能会交换到磁盘，这比RAM慢。尝试添加内存。
CPU：使用Amazon CloudWatch跟踪CPU。 非常小心与t2个实例（见下文）。
磁盘速度：如果作业是磁盘密集型的，或者内存正在交换到磁盘，则会影响性能 - 尤其是对于数据库。 Amazon EBS是网络连接磁盘，因此网络速度实际上可以降低磁盘速度。
网络速度：由于Amazon EC2的多租户设计，故意限制网络带宽。可用的网络带宽量取决于使用的实例类型。

您正在使用t2.small个实例。它有：

内存： 2GB（这比你自己笔记本电脑上的4GB还要少）
CPU： t2系列功能非常强大，但t2.small只能获得平均 20％的CPU （见下文）。
网络：t2.small被评为低至中等网络带宽。

您的CPU正在记录60％，而t2.small仅限于CPU的20％这一事实表明该实例消耗的CPU信用额度比获得的速度快。这导致最终耗尽CPU积分，从而将机器限制为CPU的20％。这极有可能影响您的表现。您可以在Amazon CloudWatch中查看CPU贷方余额。

请参阅：T2 Instances documentation了解CPU Credits。

t2.small的网络带宽相对较低。这会影响Internet访问以及与Amazon EBS存储卷的通信。鉴于您的应用程序正在并行下载大量网页，然后将它们写入磁盘，这也是您系统的潜在瓶颈。

底线：与笔记本电脑上的性能进行比较时，正在使用的实例具有较少的内存，可能会因耗尽而 CPU 更少由于网络流量较大，CPU信用额度可能较慢磁盘访问。

我建议您使用更大的实例类型确认性能得到改善，然后尝试使用不同的实例类型（在t2家庭和外部它确定什么尺寸的机器给你最好的性价比。

继续监控 CPU，内存和网络性能以确定主要瓶颈，然后以解决该瓶颈为目标。

在AWS EC2上运行时，Scrapy蜘蛛大幅减速

1 个答案: