document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-26 21:30:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

PRF:20190218 SPEED TEST- x86 vs. ARM for Web Crawling in Python.md

Browse Source 
@HankChow
This commit is contained in:
Xingyu.Wang 2019-03-21 21:28:53 +08:00
parent fdbe5a9b57
commit 52a44c8e99
1 changed files with 20 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
translated/tech/20190218 SPEED TEST- x86 vs. ARM for Web Crawling in Python.md
View File

@ -96,25 +96,25 @@ x86 方面我们选择 [1-S][11]，每月的费用是 4 欧元。它拥有 2 个
在镜像库中没有 Debian 发行版的镜像，因此我选择了 Ubuntu 18.04。 在镜像库中没有 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 保持繁忙的爬虫任务了。 但我实际爬取的网站可能不足 500 个，因为我需要遵循网站的 `robot.txt` 协定，另外还有些网站需要提交 javascript 请求，也不一定会计算在内。但这已经是一个足以让 CPU 保持繁忙的爬虫任务了。
Python 的[全局解释器锁][16]机制会让我的程序只能用到一个 CPU 线程。为了测试多线程的性能，我需要启动多个独立的爬虫程序进程。 Python 的[全局解释器锁][16]机制会让我的程序只能用到一个 CPU 线程。为了测试多线程的性能，我需要启动多个独立的爬虫程序进程。
因此我还编写了 `butthead.py`，尽管 Butthead 很粗鲁，它也比 Beavis 要略胜一筹（译者注：beavis 和 butt-head 都是 Mike Judge 的动画片《Beavis and Butt-head》中的角色）。 因此我还编写了 `butthead.py`，尽管大头蛋很粗鲁，它也总是比瘪四要略胜一筹。
我将整个爬虫任务拆分为多个部分，这可能会对爬取到的链接数量有一点轻微的影响。但无论如何，每次爬取都会有所不同，我们要关注的是爬取了多少个页面，以及耗时多长。 我将整个爬虫任务拆分为多个部分，这可能会对爬取到的链接数量有一点轻微的影响。但无论如何，每次爬取都会有所不同，我们要关注的是爬取了多少个页面，以及耗时多长。
### 在 ARM 服务器上安装 Scrapy ### 在 ARM 服务器上安装 Scrapy
安装 Scrapy 的过程与芯片的不同架构没有太大的关系，都是安装 pip 和相关的依赖包之后，再使用 pip 来安装Scrapy。 安装 Scrapy 的过程与芯片的不同架构没有太大的关系，都是安装 `pip` 和相关的依赖包之后，再使用 `pip` 来安装 Scrapy。
据我观察，在使用 ARM 的机器上使用 pip 安装 Scrapy 确实耗时要长一点，我估计是由于需要从源码编译为二进制文件。 据我观察，在使用 ARM 的机器上使用 `pip` 安装 Scrapy 确实耗时要长一点，我估计是由于需要从源码编译为二进制文件。
在 Scrapy 安装结束后，就可以通过 shell 来查看它的工作状态了。 在 Scrapy 安装结束后，就可以通过 shell 来查看它的工作状态了。
@ -145,7 +145,7 @@ Scrapy 的官方文档建议[将爬虫程序的 CPU 使用率控制在 80% 到 9
我使用了 [top][18] 工具来查看爬虫程序运行期间的 CPU 使用率。在任务刚开始的时候，两者的 CPU 使用率都达到了 100%，但 ThunderX 大部分时间都达到了 CPU 的极限，无法看出来 Atom 的性能会比 ThunderX 超出多少。 我使用了 [top][18] 工具来查看爬虫程序运行期间的 CPU 使用率。在任务刚开始的时候，两者的 CPU 使用率都达到了 100%，但 ThunderX 大部分时间都达到了 CPU 的极限，无法看出来 Atom 的性能会比 ThunderX 超出多少。
通过 top 工具，我还观察了它们的内存使用情况。随着爬取任务的进行，ARM 机器的内存使用率最终达到了 14.7%，而 x86 则最终是 15%。 通过 `top` 工具，我还观察了它们的内存使用情况。随着爬取任务的进行，ARM 机器的内存使用率最终达到了 14.7%，而 x86 则最终是 15%。
从运行日志还可以看出来，当 CPU 使用率到达极限时，会有大量的超时页面产生，最终导致页面丢失。这也是合理出现的现象，因为 CPU 过于繁忙会无法完整地记录所有爬取到的页面。 从运行日志还可以看出来，当 CPU 使用率到达极限时，会有大量的超时页面产生，最终导致页面丢失。这也是合理出现的现象，因为 CPU 过于繁忙会无法完整地记录所有爬取到的页面。
@ -158,19 +158,19 @@ Scrapy 的官方文档建议[将爬虫程序的 CPU 使用率控制在 80% 到 9
| a1.medium | 100m 39.900s | 41,294 | 24,612.725 | 1.03605 | | a1.medium | 100m 39.900s | 41,294 | 24,612.725 | 1.03605 |
| t2.small | 78m 53.171s | 41,200 | 31,336.286 | 0.73397 | | 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% 之间。 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 积分并没有被消耗。 t2.small 型号的机器性能让人费解。CPU 利用率大概 20%，最高才达到 35%，是因为手册中说的“20% 的基准性能，可以使用 CPU 积分突破这个基准”吗？但在控制台中可以看到 CPU 积分并没有被消耗。
为了确认这一点，我安装了 [stress][19] 这个软件，然后运行了一段时间，这个时候发现居然可以把 CPU 使用率提高到 100% 了。 为了确认这一点，我安装了 [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，Graviton 处理器则只是有一段时间如此。可以认为 Graviton 略胜一筹。
然而，如果 CPU 积分耗尽了呢？这种情况下的对比可能更为公平。为了测试这种情况，我使用 stress 把所有的 CPU 积分用完，然后再次启动了爬虫任务。 然而，如果 CPU 积分耗尽了呢？这种情况下的对比可能更为公平。为了测试这种情况，我使用 `stress` 把所有的 CPU 积分用完，然后再次启动了爬虫任务。
在没有 CPU 积分的情况下，CPU 使用率在 27% 就到达极限不再上升了，同时又出现了丢失页面的现象。这么看来，它的性能比负载较低的时候更差。 在没有 CPU 积分的情况下，CPU 使用率在 27% 就到达极限不再上升了，同时又出现了丢失页面的现象。这么看来，它的性能比负载较低的时候更差。
@ -192,7 +192,7 @@ a1.medium 型号机器的 CPU 使用率在爬虫任务开始后 5 分钟飙升
将爬虫任务分散到不同的进程中，可以有效利用机器所提供的多个核心。 将爬虫任务分散到不同的进程中，可以有效利用机器所提供的多个核心。
一开始，我将爬虫任务分布在 10 个不同的进程中并同时启动，结果发现比仅使用 1 个进程的时候还要慢。 一开始，我将爬虫任务分布在 10 个不同的进程中并同时启动，结果发现比每个核心仅使用 1 个进程的时候还要慢。
经过尝试，我得到了一个比较好的方案。把爬虫任务分布在 10 个进程中，但每个核心只启动 1 个进程，在每个进程接近结束的时候，再从剩余的进程中选出 1 个进程启动起来。 经过尝试，我得到了一个比较好的方案。把爬虫任务分布在 10 个进程中，但每个核心只启动 1 个进程，在每个进程接近结束的时候，再从剩余的进程中选出 1 个进程启动起来。
@ -200,7 +200,7 @@ a1.medium 型号机器的 CPU 使用率在爬虫任务开始后 5 分钟飙升
想要预估某个域名的页面量，一定程度上可以参考这个域名主页的链接数量。我用另一个程序来对这个数量进行了统计，然后按照降序排序。经过这样的预处理之后，只会额外增加 1 分钟左右的时间。 想要预估某个域名的页面量，一定程度上可以参考这个域名主页的链接数量。我用另一个程序来对这个数量进行了统计，然后按照降序排序。经过这样的预处理之后，只会额外增加 1 分钟左右的时间。
结果，爬虫运行的总耗时找过了两个小时！毕竟把链接最多的域名都堆在同一个进程中也存在一定的弊端。 结果，爬虫运行的总耗时超过了两个小时！毕竟把链接最多的域名都堆在同一个进程中也存在一定的弊端。
针对这个问题，也可以通过调整各个进程爬取的域名数量来进行优化，又或者在排序之后再作一定的修改。不过这种优化可能有点复杂了。 针对这个问题，也可以通过调整各个进程爬取的域名数量来进行优化，又或者在排序之后再作一定的修改。不过这种优化可能有点复杂了。
@ -227,7 +227,9 @@ a1.medium 型号机器的 CPU 使用率在爬虫任务开始后 5 分钟飙升
### 结论 ### 结论
从上面的数据来看，不同架构的 CPU 性能和它们的问世时间没有直接的联系，AWS Graviton 是单线程情况下性能最佳的。 从上面的数据来看，对于性能而言，CPU 的架构并没有它们的问世时间重要，2018 年生产的 AWS Graviton 是单线程情况下性能最佳的。
你当然可以说按核心来比，Xeon 仍然赢了。但是，你不但需要计算美元的变化，甚至还要计算线程数。
另外在性能方面 2017 年生产的 Atom 轻松击败了 2014 年生产的 ThunderX，而 ThunderX 则在性价比方面占优。当然，如果你使用 AWS 的机器的话，还是使用 Graviton 吧。 另外在性能方面 2017 年生产的 Atom 轻松击败了 2014 年生产的 ThunderX，而 ThunderX 则在性价比方面占优。当然，如果你使用 AWS 的机器的话，还是使用 Graviton 吧。
@ -245,7 +247,7 @@ a1.medium 型号机器的 CPU 使用率在爬虫任务开始后 5 分钟飙升
要运行这些代码，需要预先安装 Scrapy，并且需要 [Moz 上排名前 500 的网站][21]的 csv 文件。如果要运行 `butthead.py`，还需要安装 [psutil][22] 这个库。 要运行这些代码，需要预先安装 Scrapy，并且需要 [Moz 上排名前 500 的网站][21]的 csv 文件。如果要运行 `butthead.py`，还需要安装 [psutil][22] 这个库。
##### beavis.py *beavis.py*
``` ```
import scrapy import scrapy
@ -349,7 +351,7 @@ if __name__ == '__main__':
print('Uh huhuhuhuh. It said wood ' + str(wood) + ' times.') print('Uh huhuhuhuh. It said wood ' + str(wood) + ' times.')
``` ```
##### butthead.py *butthead.py*
``` ```
import scrapy, time, psutil 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] 作者：[James Mawson][a]
选题：[lujun9972][b] 选题：[lujun9972][b]
译者：[HankChow](https://github.com/HankChow) 译者：[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/) 荣誉推出 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出