Node.js网络抓取优化

时间:2015-09-14 01:22:43

标签: node.js web-scraping

任务:

  1. 从网页上抓取HTML
  2. 解析html
  3. 清理数据(删除空格,执行基本正则表达式)
  4. 将数据保留在SQL数据库中。
  5. 目标是尽快完成这4项任务,以下是一些可能的示例方法。

    可能的样本方法

    多步骤1:抓取所有页面并将html存储为.txt文件。将所有html存储为文本后,运行一个单独的模块来解析/清除/保留数据。

    多步骤2:Scrape / Parse / Clean数据并存储在.txt文件中。运行单独的模块以将数据插入数据库。

    单步:一步完成Scrape / Parse / Clean / Persist数据。

    假设:

    1. 1个用于抓取的专用服务器
    2. 磁盘空间不受限制
    3. 互联网连接是您的普通家庭连接
    4. 内存(8GB)
    5. 对任何网页都没有速率限制
    6. 用户希望抓取100万页
    7. 我还没有对node.js进行足够的测试来建立最佳实践,但是我们将非常感谢您对优化这些任务的任何见解。

      显然,有一些未解答的问题(典型页面上有多少html,解析多少,请求/响应延迟,用于解析数据的框架等等),但是高级别最好实践/关键考虑将是有益的。感谢。

1 个答案:

答案 0 :(得分:2)

如果出现这样的问题,您只能预测哪些方面会真正控制您的瓶颈所在。所以,你从一个聪明但不复杂的实现开始,你花了相当多的时间来弄清楚如何衡量你的表现以及瓶颈在哪里。

然后,根据对瓶颈所在位置的了解,您会提出一个建议的设计更改,实施该更改并查看您在整体吞吐量方面的差异。然后你再次测量,再次测量,看看你的新瓶颈在哪里,提出一个关于如何击败瓶颈,实施,测量,理论化,迭代等的新理论......

你真的不想过度设计或过度复杂化第一个实现,因为你认为真正的瓶颈会很容易出错。

所以,我可能会从这样的设计开始:

创建一个node.js进程,除了下载页面并将其写入磁盘之外绝对不会发生任何事情。在任何地方都不使用任何异步I / O,并使其可以配置为同时进行多少次同步页面下载。不解析,只需将原始数据写入磁盘即可。您将希望找到一种非常快速的方法来存储哪个URL是哪个文件。这可能就像将信息附加到文本文件一样简单,也可能是数据库写入,但想法是你只想让它快速。

然后,创建另一个node.js进程,该进程从磁盘重复抓取文件,解析它们,清理数据并将数据保存到SQL数据库。

自行运行第一个node.js进程并让它运行,直到它收集1,000个网页或15分钟(以先到者为准)来衡量您最初的吞吐量。在它运行时,请注意计算机上的CPU利用率和网络利用率。如果您已经处于第一个node.js进程可能需要的范围内,那么您已经完成了第一个node.js进程。如果你想要它更快,那么你需要弄清楚你的瓶颈在哪里。如果您受CPU限制(此I / O任务不太可能),那么您可以集群并运行多个这些node.js进程,为每个进程提供一组要获取的URL和一个单独的位置来编写其收集的数据。你很可能受到I / O限制。这可能是因为您没有完全饱和现有的网络连接(node.js进程花费太多时间等待I / O),或者您已经使网络连接饱和,现在它已成为瓶颈。你必须弄清楚它们是哪一个。如果您同时添加更多网页提取并且性能不会提高甚至降低,那么您的网络连接可能已经饱和了。您还必须注意node.js中的文件I / O子系统是否饱和,该子系统使用限制线程池来实现异步I / O.

对于第二个node.js进程,您遵循类似的过程。给它1000个网页,看看它能以多快的速度处理它们。由于您确实有I / O从磁盘读取文件并写入数据库,因此您希望一次解析多个页面,以便在读取或写入一个页面时最大限度地利用CPU出。您可以编写一个node.js进程来一次处理多个解析项目,也可以聚合单个node.js进程。如果服务器中有多个CPU,那么您可能希望拥有至少与CPU相同的进程数。与URL提取程序进程不同,用于解析的代码可能会被认真优化以加快速度。但是,与其他性能问题一样,在您知道自己受CPU限制并且它阻止了您之前,不要试图过度优化该代码。

然后,如果您的SQL数据库可以在另一个盒子上或至少使用另一个磁盘,那可能是一件好事,因为它将磁盘写入与其他磁盘写入分开。

在前几个步骤之后,您将完全取决于您从前几个步骤中学到的内容。您测量瓶颈所在的能力以及设计快速实验来测试瓶颈理论对于快速进步并且不会在错误的优化上浪费开发时间非常重要。

仅供参考,一些家庭互联网连接ISP可能会根据您的数据请求数量和速率引发一些警报。他们对这些信息的处理方式可能因ISP而异。我认为大多数人最终都有能力对你的连接进行速率限制,以保护共享同一管道的其他人的服务质量,但我不知道他们何时/是否会这样做。

这听起来像是一个非常有趣的项目,试图优化和充分利用。它将成为中高级软件类的最佳项目。