From 52a44c8e99b0f40f366996698ff9c5d158b9c44d Mon Sep 17 00:00:00 2001 From: "Xingyu.Wang" Date: Thu, 21 Mar 2019 21:28:53 +0800 Subject: [PATCH] PRF:20190218 SPEED TEST- x86 vs. ARM for Web Crawling in Python.md @HankChow --- ... x86 vs. ARM for Web Crawling in Python.md | 38 ++++++++++--------- 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/translated/tech/20190218 SPEED TEST- x86 vs. ARM for Web Crawling in Python.md b/translated/tech/20190218 SPEED TEST- x86 vs. ARM for Web Crawling in Python.md index b074a11217..bda3628536 100644 --- a/translated/tech/20190218 SPEED TEST- x86 vs. ARM for Web Crawling in Python.md +++ b/translated/tech/20190218 SPEED TEST- x86 vs. ARM for Web Crawling in Python.md @@ -96,25 +96,25 @@ x86 方面我们选择 [1-S][11]，每月的费用是 4 欧元。它拥有 2 个 在镜像库中没有 Debian 发行版的镜像，因此我选择了 Ubuntu 18.04。 -### Beavis and Butthead Do Moz’s Top 500 +### 瘪四与大头蛋爬取 Moz 排行榜前 500 的网站 -要测试这些 VPS 的 CPU 性能，就该使用爬虫了。一般来说都是对几个网站在尽可能短的时间里发出尽可能多的请求，但这种操作太暴力了，我的做法是只向大量网站发出少数几个请求。 +要测试这些 VPS 的 CPU 性能，就该使用爬虫了。一个方法是对几个网站在尽可能短的时间里发出尽可能多的请求，但这种操作不太礼貌，我的做法是只向大量网站发出少数几个请求。 -为此，我编写了 `beavs.py` 这个爬虫程序（致敬我最喜欢的物理学家和制片人 Mike Judge）。这个程序会将 Moz 上排行前 500 的网站都爬取 3 层的深度，并计算 “wood” 和 “ass” 这两个单词在 HTML 文件中出现的次数。 +为此，我编写了 `beavis.py`（瘪四）这个爬虫程序（致敬我最喜欢的物理学家和制片人 Mike Judge）。这个程序会将 Moz 上排行前 500 的网站都爬取 3 层的深度，并计算 “wood” 和 “ass” 这两个单词在 HTML 文件中出现的次数。（LCTT 译注：beavis（瘪四）和 butt-head（大头蛋） 都是 Mike Judge 的动画片《瘪四与大头蛋》中的角色） 但我实际爬取的网站可能不足 500 个，因为我需要遵循网站的 `robot.txt` 协定，另外还有些网站需要提交 javascript 请求，也不一定会计算在内。但这已经是一个足以让 CPU 保持繁忙的爬虫任务了。 Python 的[全局解释器锁][16]机制会让我的程序只能用到一个 CPU 线程。为了测试多线程的性能，我需要启动多个独立的爬虫程序进程。 -因此我还编写了 `butthead.py`，尽管 Butthead 很粗鲁，它也比 Beavis 要略胜一筹（译者注：beavis 和 butt-head 都是 Mike Judge 的动画片《Beavis and Butt-head》中的角色）。 +因此我还编写了 `butthead.py`，尽管大头蛋很粗鲁，它也总是比瘪四要略胜一筹。 我将整个爬虫任务拆分为多个部分，这可能会对爬取到的链接数量有一点轻微的影响。但无论如何，每次爬取都会有所不同，我们要关注的是爬取了多少个页面，以及耗时多长。 ### 在 ARM 服务器上安装 Scrapy -安装 Scrapy 的过程与芯片的不同架构没有太大的关系，都是安装 pip 和相关的依赖包之后，再使用 pip 来安装Scrapy。 +安装 Scrapy 的过程与芯片的不同架构没有太大的关系，都是安装 `pip` 和相关的依赖包之后，再使用 `pip` 来安装 Scrapy。 -据我观察，在使用 ARM 的机器上使用 pip 安装 Scrapy 确实耗时要长一点，我估计是由于需要从源码编译为二进制文件。 +据我观察，在使用 ARM 的机器上使用 `pip` 安装 Scrapy 确实耗时要长一点，我估计是由于需要从源码编译为二进制文件。 在 Scrapy 安装结束后，就可以通过 shell 来查看它的工作状态了。 @@ -145,7 +145,7 @@ Scrapy 的官方文档建议[将爬虫程序的 CPU 使用率控制在 80% 到 9 我使用了 [top][18] 工具来查看爬虫程序运行期间的 CPU 使用率。在任务刚开始的时候，两者的 CPU 使用率都达到了 100%，但 ThunderX 大部分时间都达到了 CPU 的极限，无法看出来 Atom 的性能会比 ThunderX 超出多少。 -通过 top 工具，我还观察了它们的内存使用情况。随着爬取任务的进行，ARM 机器的内存使用率最终达到了 14.7%，而 x86 则最终是 15%。 +通过 `top` 工具，我还观察了它们的内存使用情况。随着爬取任务的进行，ARM 机器的内存使用率最终达到了 14.7%，而 x86 则最终是 15%。 从运行日志还可以看出来，当 CPU 使用率到达极限时，会有大量的超时页面产生，最终导致页面丢失。这也是合理出现的现象，因为 CPU 过于繁忙会无法完整地记录所有爬取到的页面。 @@ -158,19 +158,19 @@ Scrapy 的官方文档建议[将爬虫程序的 CPU 使用率控制在 80% 到 9 | a1.medium | 100m 39.900s | 41,294 | 24,612.725 | 1.03605 | | t2.small | 78m 53.171s | 41,200 | 31,336.286 | 0.73397 | -为了方便比较，对于在 AWS 上跑的爬虫，我记录的指标和 Scaleway 上一致，但似乎没有达到预期的效果。这里我没有使用 top，而是使用了 AWS 提供的控制台来监控 CPU 的使用情况，从监控结果来看，我的爬虫程序并没有完全用到这两款服务器所提供的所有性能。 +为了方便比较，对于在 AWS 上跑的爬虫，我记录的指标和 Scaleway 上一致，但似乎没有达到预期的效果。这里我没有使用 `top`，而是使用了 AWS 提供的控制台来监控 CPU 的使用情况，从监控结果来看，我的爬虫程序并没有完全用到这两款服务器所提供的所有性能。 a1.medium 型号的机器尤为如此，在任务开始阶段，它的 CPU 使用率达到了峰值 45%，但随后一直在 20% 到 30% 之间。 -让我有点感到意外的是，这个程序在 ARM 处理器上的运行速度相当慢，但却远未达到 Graviton CPU 能力的极限，而在 Inter 处理器上则可以在某些时候达到 CPU 能力的极限。它们运行的代码是完全相同的，处理器的不同架构可能导致了对代码的不同处理方式。 +让我有点感到意外的是，这个程序在 ARM 处理器上的运行速度相当慢，但却远未达到 Graviton CPU 能力的极限，而在 Intel Atom 处理器上则可以在某些时候达到 CPU 能力的极限。它们运行的代码是完全相同的，处理器的不同架构可能导致了对代码的不同处理方式。 -个中原因无论是由于处理器本身的特性，还是而今是文件的编译，又或者是两者皆有，对我来说都是一个黑盒般的存在。我认为，既然在 AWS 机器上没有达到 CPU 处理能力的极限，那么只有在 Scaleway 机器上跑出来的性能数据是可以作为参考的。 +个中原因无论是由于处理器本身的特性，还是二进制文件的编译，又或者是两者皆有，对我来说都是一个黑盒般的存在。我认为，既然在 AWS 机器上没有达到 CPU 处理能力的极限，那么只有在 Scaleway 机器上跑出来的性能数据是可以作为参考的。 t2.small 型号的机器性能让人费解。CPU 利用率大概 20%，最高才达到 35%，是因为手册中说的“20% 的基准性能，可以使用 CPU 积分突破这个基准”吗？但在控制台中可以看到 CPU 积分并没有被消耗。 为了确认这一点，我安装了 [stress][19] 这个软件，然后运行了一段时间，这个时候发现居然可以把 CPU 使用率提高到 100% 了。 -显然，我需要调整一下它们的配置文件。我将 CONCURRENT_REQUESTS 参数设置为 5000，将 REACTOR_THREADPOOL_MAXSIZE 参数设置为 120，将爬虫任务的负载调得更大。 +显然，我需要调整一下它们的配置文件。我将 `CONCURRENT_REQUESTS` 参数设置为 5000，将 `REACTOR_THREADPOOL_MAXSIZE` 参数设置为 120，将爬虫任务的负载调得更大。 | 机器种类 | 耗时 | 爬取页面数 | 每小时爬取页面数 | 每万页面费用（美元） | | ----------------------- | ----------- | ---------- | ---------------- | -------------------- | @@ -184,7 +184,7 @@ a1.medium 型号机器的 CPU 使用率在爬虫任务开始后 5 分钟飙升 现在我们看到它们的性能都差不多了。但至强处理器的线程持续跑满了 CPU，Graviton 处理器则只是有一段时间如此。可以认为 Graviton 略胜一筹。 -然而，如果 CPU 积分耗尽了呢？这种情况下的对比可能更为公平。为了测试这种情况，我使用 stress 把所有的 CPU 积分用完，然后再次启动了爬虫任务。 +然而，如果 CPU 积分耗尽了呢？这种情况下的对比可能更为公平。为了测试这种情况，我使用 `stress` 把所有的 CPU 积分用完，然后再次启动了爬虫任务。 在没有 CPU 积分的情况下，CPU 使用率在 27% 就到达极限不再上升了，同时又出现了丢失页面的现象。这么看来，它的性能比负载较低的时候更差。 @@ -192,7 +192,7 @@ a1.medium 型号机器的 CPU 使用率在爬虫任务开始后 5 分钟飙升 将爬虫任务分散到不同的进程中，可以有效利用机器所提供的多个核心。 -一开始，我将爬虫任务分布在 10 个不同的进程中并同时启动，结果发现比仅使用 1 个进程的时候还要慢。 +一开始，我将爬虫任务分布在 10 个不同的进程中并同时启动，结果发现比每个核心仅使用 1 个进程的时候还要慢。 经过尝试，我得到了一个比较好的方案。把爬虫任务分布在 10 个进程中，但每个核心只启动 1 个进程，在每个进程接近结束的时候，再从剩余的进程中选出 1 个进程启动起来。 @@ -200,7 +200,7 @@ a1.medium 型号机器的 CPU 使用率在爬虫任务开始后 5 分钟飙升 想要预估某个域名的页面量，一定程度上可以参考这个域名主页的链接数量。我用另一个程序来对这个数量进行了统计，然后按照降序排序。经过这样的预处理之后，只会额外增加 1 分钟左右的时间。 -结果，爬虫运行的总耗时找过了两个小时！毕竟把链接最多的域名都堆在同一个进程中也存在一定的弊端。 +结果，爬虫运行的总耗时超过了两个小时！毕竟把链接最多的域名都堆在同一个进程中也存在一定的弊端。 针对这个问题，也可以通过调整各个进程爬取的域名数量来进行优化，又或者在排序之后再作一定的修改。不过这种优化可能有点复杂了。 @@ -227,7 +227,9 @@ a1.medium 型号机器的 CPU 使用率在爬虫任务开始后 5 分钟飙升 ### 结论 -从上面的数据来看，不同架构的 CPU 性能和它们的问世时间没有直接的联系，AWS Graviton 是单线程情况下性能最佳的。 +从上面的数据来看，对于性能而言，CPU 的架构并没有它们的问世时间重要，2018 年生产的 AWS Graviton 是单线程情况下性能最佳的。 + +你当然可以说按核心来比，Xeon 仍然赢了。但是，你不但需要计算美元的变化，甚至还要计算线程数。 另外在性能方面 2017 年生产的 Atom 轻松击败了 2014 年生产的 ThunderX，而 ThunderX 则在性价比方面占优。当然，如果你使用 AWS 的机器的话，还是使用 Graviton 吧。 @@ -245,7 +247,7 @@ a1.medium 型号机器的 CPU 使用率在爬虫任务开始后 5 分钟飙升 要运行这些代码，需要预先安装 Scrapy，并且需要 [Moz 上排名前 500 的网站][21]的 csv 文件。如果要运行 `butthead.py`，还需要安装 [psutil][22] 这个库。 -##### beavis.py +*beavis.py* ``` import scrapy @@ -349,7 +351,7 @@ if __name__ == '__main__': print('Uh huhuhuhuh. It said wood ' + str(wood) + ' times.') ``` -##### butthead.py +*butthead.py* ``` import scrapy, time, psutil @@ -496,7 +498,7 @@ via: https://blog.dxmtechsupport.com.au/speed-test-x86-vs-arm-for-web-crawling-i 作者：[James Mawson][a] 选题：[lujun9972][b] 译者：[HankChow](https://github.com/HankChow) -校对：[校对者ID](https://github.com/校对者ID) +校对：[wxy](https://github.com/wxy) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出