Merge pull request #12862 from wxy/20190218-SPEED-TEST--x86-vs.-ARM-for-Web-Crawling-in-Python

PRF&PUB:20190218 SPEED TEST  x86 vs. ARM for Web Crawling in Python

published/20190218 SPEED TEST- x86 vs. ARM for Web Crawling in Python.md

@@ -1,8 +1,8 @@
 [#]: collector: (lujun9972)
 [#]: translator: (HankChow)
-[#]: reviewer: ( )
-[#]: publisher: ( )
-[#]: url: ( )
+[#]: reviewer: (wxy)
+[#]: publisher: (wxy)
+[#]: url: (https://linux.cn/article-10640-1.html)
 [#]: subject: (SPEED TEST: x86 vs. ARM for Web Crawling in Python)
 [#]: via: (https://blog.dxmtechsupport.com.au/speed-test-x86-vs-arm-for-web-crawling-in-python/)
 [#]: author: (James Mawson https://blog.dxmtechsupport.com.au/author/james-mawson/)
@@ -12,7 +12,7 @@ x86 和 ARM 的 Python 爬虫速度对比
 
 ![][1]
 
-如果你的老板给你的任务是不断地访问竞争对手的网站，把对方商品的价格记录下来，而且要纯手工操作，恐怕你会想要把整个办公室都烧掉。
+假如说，如果你的老板给你的任务是一次又一次地访问竞争对手的网站，把对方商品的价格记录下来，而且要纯手工操作，恐怕你会想要把整个办公室都烧掉。
 
 之所以现在网络爬虫的影响力如此巨大，就是因为网络爬虫可以被用于追踪客户的情绪和趋向、搜寻空缺的职位、监控房地产的交易，甚至是获取 UFC 的比赛结果。除此以外，还有很多意想不到的用途。
 
@@ -32,21 +32,21 @@ x86 和 ARM 的 Python 爬虫速度对比
 
 ARM 是目前世界上最流行的 CPU 架构。
 
-但 ARM 架构处理器在很多人眼中的地位只是作为一个节省成本的选择，而不是跑在生产环境中的处理器的首选。
+但 ARM 架构处理器在很多人眼中的地位只是作为一个省钱又省电的选择，而不是跑在生产环境中的处理器的首选。
 
-然而，诞生于英国剑桥的 ARM CPU，最初是用于昂贵的 [Acorn Archimedes][4] 计算机上的，这是当时世界上最强大的计算机，它的运算速度甚至比最快的 386 还要快好几倍。
+然而，诞生于英国剑桥的 ARM CPU，最初是用于极其昂贵的 [Acorn Archimedes][4] 计算机上的，这是当时世界上最强大的桌面计算机，甚至在很长一段时间内，它的运算速度甚至比最快的 386 还要快好几倍。
 
 Acorn 公司和 Commodore、Atari 的理念类似，他们认为一家伟大的计算机公司就应该制造出伟大的计算机，让人感觉有点目光短浅。而比尔盖茨的想法则有所不同，他力图在更多不同种类和价格的 x86 机器上使用他的 DOS 系统。
 
-拥有大量用户基础的平台会让更多开发者开发出众多适应平台的软件，而软件资源丰富又让计算机更受用户欢迎。
+拥有大量用户基数的平台会成为第三方开发者开发软件的平台，而软件资源丰富又会让你的计算机更受用户欢迎。
 
-即使是苹果公司也在这上面吃到了苦头，不得不在 x86 芯片上投入大量的财力。最终，这些芯片不再仅仅用于专业的计算任务，走进了人们的日常生活中。
+即使是苹果公司也几乎被打败。在 x86 芯片上投入大量的财力，最终，这些芯片被用于生产环境计算任务。
 
-ARM 架构也并没有消失。基于 ARM 架构的芯片不仅运算速度快，同时也非常节能。因此诸如机顶盒、PDA、数码相机、MP3 播放器这些电子产品多数都会采用 ARM 架构的芯片，甚至在很多需要用电池、不配备大散热风扇的电子产品上，都可以见到 ARM 芯片的身影。
+但 ARM 架构也并没有消失。基于 ARM 架构的芯片不仅运算速度快，同时也非常节能。因此诸如机顶盒、PDA、数码相机、MP3 播放器这些电子产品多数都会采用 ARM 架构的芯片，甚至在很多需要用电池或不配备大散热风扇的电子产品上，都可以见到 ARM 芯片的身影。
 
-而 ARM 则脱离 Acorn 成为了一种独立的商业模式，他们不生产实物芯片，仅仅是向芯片生产厂商出售相关的知识产权。
+而 ARM 则脱离 Acorn 成为了一种特殊的商业模式，他们不生产实物芯片，仅仅是向芯片生产厂商出售相关的知识产权。
 
-因此，ARM 芯片被应用于很多手机和平板电脑上。当 Linux 被移植到这种架构的芯片上时，开源技术的大门就已经向它打开了，这才让我们今天得以在这些芯片上运行 web 爬虫程序。
+因此，这或多或少是 ARM 芯片被应用于如此之多的手机和平板电脑上的原因。当 Linux 被移植到这种架构的芯片上时，开源技术的大门就已经向它打开了，这才让我们今天得以在这些芯片上运行 web 爬虫程序。
 
 #### 服务器端的 ARM
 
@@ -64,11 +64,11 @@ ARM 架构也并没有消失。基于 ARM 架构的芯片不仅运算速度快
 
 #### Scaleway
 
-Scaleway 自身的定位是“专为开发者设计”。我觉得这个定位很准确，对于开发原型来说，Scaleway 提供的产品确实可以作为一个很好的沙盒环境。
+Scaleway 自身的定位是“专为开发者设计”。我觉得这个定位很准确，对于开发和原型设计来说，Scaleway 提供的产品确实可以作为一个很好的沙盒环境。
 
-Scaleway 提供了一个简洁的页面，让用户可以快速地从主页进入 bash shell 界面。对于很多小企业、自由职业者或者技术顾问，如果想要运行 web 爬虫，这个产品毫无疑问是一个物美价廉的选择。
+Scaleway 提供了一个简洁的仪表盘页面，让用户可以快速地从主页进入 bash shell 界面。对于很多小企业、自由职业者或者技术顾问，如果想要运行 web 爬虫，这个产品毫无疑问是一个物美价廉的选择。
 
-ARM 方面我们选择 [ARM64-2GB][10] 这一款服务器，每月只需要 3 欧元。它带有 4 个 Cavium ThunderX 核心，是在 2014 年推出的第一款服务器级的 ARMv8 处理器。但现在看来它已经显得有点落后了，并逐渐被更新的 ThunderX2 取代。
+ARM 方面我们选择 [ARM64-2GB][10] 这一款服务器，每月只需要 3 欧元。它带有 4 个 Cavium ThunderX 核心，这是在 2014 年推出的第一款服务器级的 ARMv8 处理器。但现在看来它已经显得有点落后了，并逐渐被更新的 ThunderX2 取代。
 
 x86 方面我们选择 [1-S][11]，每月的费用是 4 欧元。它拥有 2 个英特尔 Atom C3995 核心。英特尔的 Atom 系列处理器的特点是低功耗、单线程，最初是用在笔记本电脑上的，后来也被服务器所采用。
 
@@ -76,43 +76,45 @@ x86 方面我们选择 [1-S][11]，每月的费用是 4 欧元。它拥有 2 个
 
 为了避免我不能熟练使用包管理器的尴尬局面，两方的操作系统我都会选择使用 Debian 9。
 
-#### Amazon Web Services
+#### Amazon Web Services（AWS）
 
-当你还在注册 AWS 账号的时候，使用 Scaleway 的用户可能已经把提交信用卡信息、启动 VPS 实例、添加sudoer、安装依赖包这一系列流程都完成了。AWS 的操作相对来说比较繁琐，甚至需要详细阅读手册才能知道你正在做什么。
+当你还在注册 AWS 账号的时候，使用 Scaleway 的用户可能已经把提交信用卡信息、启动 VPS 实例、添加 sudo 用户、安装依赖包这一系列流程都完成了。AWS 的操作相对来说比较繁琐，甚至需要详细阅读手册才能知道你正在做什么。
 
 当然这也是合理的，对于一些需求复杂或者特殊的企业用户，确实需要通过详细的配置来定制合适的使用方案。
 
-我们所采用的 AWS Graviton 处理器是 AWS EC2（Elastic Compute Cloud）的一部分，我会以按需实例的方式来运行，这也是最贵但最简捷的方式。AWS 同时也提供[竞价实例][12]，这样可以用较低的价格运行实例，但实例的运行时间并不固定。如果实例需要长时间持续运行，还可以选择[预留实例][13]。
+我们所采用的 AWS Graviton 处理器是 AWS EC2（<ruby>弹性计算云<rt>Elastic Compute Cloud</rt></ruby>）的一部分，我会以按需实例的方式来运行，这也是最贵但最简捷的方式。AWS 同时也提供[竞价实例][12]，这样可以用较低的价格运行实例，但实例的运行时间并不固定。如果实例需要长时间持续运行，还可以选择[预留实例][13]。
 
 看，AWS 就是这么复杂……
 
-我们分别选择 [a1.medium][14] 和 [t2.small][15] 两种型号的实例进行对比，两者都带有 2GB 内存。这个时候问题来了，手册中提到的 vCPU 又是什么？两种型号的不同之处就在于此。
+我们分别选择 [a1.medium][14] 和 [t2.small][15] 两种型号的实例进行对比，两者都带有 2GB 内存。这个时候问题来了，这里提到的 vCPU 又是什么？两种型号的不同之处就在于此。
 
 对于 a1.medium 型号的实例，vCPU 是 AWS Graviton 芯片提供的单个计算核心。这个芯片由被亚马逊在 2015 收购的以色列厂商 Annapurna Labs 研发，是 AWS 独有的单线程 64 位 ARMv8 内核。它的按需价格为每小时 0.0255 美元。
 
-而 t2.small 型号实例使用英特尔至强系列芯片，但我不确定具体是其中的哪一款。它每个核心有两个线程，但我们并不能用到整个核心，甚至整个线程。我们能用到的只是“20% 的基准性能，可以使用 CPU 积分突破这个基准”。这可能有一定的原因，但我没有弄懂。它的按需价格是每小时 0.023 美元。
+而 t2.small 型号实例使用英特尔至强系列芯片，但我不确定具体是其中的哪一款。它每个核心有两个线程，但我们并不能用到整个核心，甚至整个线程。
+
+我们能用到的只是“20% 的基准性能，可以使用 CPU 积分突破这个基准”。这可能有一定的原因，但我没有弄懂。它的按需价格是每小时 0.023 美元。
 
 在镜像库中没有 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 来查看它的工作状态了。
 
@@ -143,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 过于繁忙会无法完整地记录所有爬取到的页面。
 
@@ -156,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，将爬虫任务的负载调得更大。
 
 | 机器种类                | 耗时        | 爬取页面数 | 每小时爬取页面数 | 每万页面费用（美元） |
 | ----------------------- | ----------- | ---------- | ---------------- | -------------------- |
@@ -182,7 +184,7 @@ a1.medium 型号机器的 CPU 使用率在爬虫任务开始后 5 分钟飙升
 
 现在我们看到它们的性能都差不多了。但至强处理器的线程持续跑满了 CPU，Graviton 处理器则只是有一段时间如此。可以认为 Graviton 略胜一筹。
 
-然而，如果 CPU 积分耗尽了呢？这种情况下的对比可能更为公平。为了测试这种情况，我使用 stress 把所有的 CPU 积分用完，然后再次启动了爬虫任务。
+然而，如果 CPU 积分耗尽了呢？这种情况下的对比可能更为公平。为了测试这种情况，我使用 `stress` 把所有的 CPU 积分用完，然后再次启动了爬虫任务。
 
 在没有 CPU 积分的情况下，CPU 使用率在 27% 就到达极限不再上升了，同时又出现了丢失页面的现象。这么看来，它的性能比负载较低的时候更差。
 
@@ -190,7 +192,7 @@ a1.medium 型号机器的 CPU 使用率在爬虫任务开始后 5 分钟飙升
 
 将爬虫任务分散到不同的进程中，可以有效利用机器所提供的多个核心。
 
-一开始，我将爬虫任务分布在 10 个不同的进程中并同时启动，结果发现比仅使用 1 个进程的时候还要慢。
+一开始，我将爬虫任务分布在 10 个不同的进程中并同时启动，结果发现比每个核心仅使用 1 个进程的时候还要慢。
 
 经过尝试，我得到了一个比较好的方案。把爬虫任务分布在 10 个进程中，但每个核心只启动 1 个进程，在每个进程接近结束的时候，再从剩余的进程中选出 1 个进程启动起来。
 
@@ -198,7 +200,7 @@ a1.medium 型号机器的 CPU 使用率在爬虫任务开始后 5 分钟飙升
 
 想要预估某个域名的页面量，一定程度上可以参考这个域名主页的链接数量。我用另一个程序来对这个数量进行了统计，然后按照降序排序。经过这样的预处理之后，只会额外增加 1 分钟左右的时间。
 
-结果，爬虫运行的总耗时找过了两个小时！毕竟把链接最多的域名都堆在同一个进程中也存在一定的弊端。
+结果，爬虫运行的总耗时超过了两个小时！毕竟把链接最多的域名都堆在同一个进程中也存在一定的弊端。
 
 针对这个问题，也可以通过调整各个进程爬取的域名数量来进行优化，又或者在排序之后再作一定的修改。不过这种优化可能有点复杂了。
 
@@ -225,7 +227,9 @@ a1.medium 型号机器的 CPU 使用率在爬虫任务开始后 5 分钟飙升
 
 ### 结论
 
-从上面的数据来看，不同架构的 CPU 性能和它们的问世时间没有直接的联系，AWS Graviton 是单线程情况下性能最佳的。
+从上面的数据来看，对于性能而言，CPU 的架构并没有它们的问世时间重要，2018 年生产的 AWS Graviton 是单线程情况下性能最佳的。
+
+你当然可以说按核心来比，Xeon 仍然赢了。但是，你不但需要计算美元的变化，甚至还要计算线程数。
 
 另外在性能方面 2017 年生产的 Atom 轻松击败了 2014 年生产的 ThunderX，而 ThunderX 则在性价比方面占优。当然，如果你使用 AWS 的机器的话，还是使用 Graviton 吧。
 
@@ -243,7 +247,7 @@ a1.medium 型号机器的 CPU 使用率在爬虫任务开始后 5 分钟飙升
 
 要运行这些代码，需要预先安装 Scrapy，并且需要 [Moz 上排名前 500 的网站][21]的 csv 文件。如果要运行 `butthead.py`，还需要安装 [psutil][22] 这个库。
 
-##### beavis.py
+*beavis.py*
 
 ```
 import scrapy
@@ -347,7 +351,7 @@ if __name__ == '__main__':
   print('Uh huhuhuhuh. It said wood ' + str(wood) + ' times.')
 ```
 
-##### butthead.py
+*butthead.py*
 
 ```
 import scrapy, time, psutil
@@ -494,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/) 荣誉推出