python - 如何在 python 中使用 urllib2 加快获取页面的速度？

Question

我有一个脚本可以获取几个网页并解析信息。

(一个例子可以在 http://bluedevilbooks.com/search/?DEPT=MATH&CLASS=103&SEC=01 看到)

我在上面运行了 cProfile，正如我所假设的，urlopen 占用了很多时间。有没有办法更快地获取页面？或者一次获取多个页面的方法？我会做任何最简单的事情，因为我是 Python 和 Web 开发的新手。

提前致谢! :)

更新:我有一个名为 fetchURLs() 的函数，我用它来制作我需要的 URL 数组
所以类似 urls = fetchURLS() .URL 都是来自 Amazon 和 eBay API 的 XML 文件(这让我很困惑，为什么加载需要这么长时间，也许我的网络主机很慢？)

我需要做的是加载每个 URL，读取每个页面，并将该数据发送到脚本的另一部分，该部分将解析和显示数据。

请注意，在获取所有页面之前，我无法执行后一部分，这就是我的问题。

另外，我相信，我的主机一次将我限制为 25 个进程，因此服务器上最简单的方法都很好:)

这是时间:

Sun Aug 15 20:51:22 2010    prof

         211352 function calls (209292 primitive calls) in 22.254 CPU seconds

   Ordered by: internal time
   List reduced from 404 to 10 due to restriction <10>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
       10   18.056    1.806   18.056    1.806 {_socket.getaddrinfo}
     4991    2.730    0.001    2.730    0.001 {method 'recv' of '_socket.socket' objects}
       10    0.490    0.049    0.490    0.049 {method 'connect' of '_socket.socket' objects}
     2415    0.079    0.000    0.079    0.000 {method 'translate' of 'unicode' objects}
       12    0.061    0.005    0.745    0.062 /usr/local/lib/python2.6/HTMLParser.py:132(goahead)
     3428    0.060    0.000    0.202    0.000 /usr/local/lib/python2.6/site-packages/BeautifulSoup.py:1306(endData)
     1698    0.055    0.000    0.068    0.000 /usr/local/lib/python2.6/site-packages/BeautifulSoup.py:1351(_smartPop)
     4125    0.053    0.000    0.056    0.000 /usr/local/lib/python2.6/site-packages/BeautifulSoup.py:118(setup)
     1698    0.042    0.000    0.358    0.000 /usr/local/lib/python2.6/HTMLParser.py:224(parse_starttag)
     1698    0.042    0.000    0.275    0.000 /usr/local/lib/python2.6/site-packages/BeautifulSoup.py:1397(unknown_starttag)

Answer 1

编辑 :我正在扩展答案以包含一个更精美的示例。我在这篇文章中发现了很多关于线程 vs. 的敌意和错误信息。异步 I/O。因此，我还添加了更多的论据来驳斥某些无效的主张。我希望这将帮助人们为正确的工作选择正确的工具。

这是对 3 天前问题的重复。

Python urllib2.open 很慢，需要更好的方法来读取几个 url_python_帮酷编程问答
Python urllib2.urlopen() is slow, need a better way to read several urls

我正在完善代码以展示如何使用线程并行获取多个网页。

import time
import threading
import Queue

# utility - spawn a thread to execute target for each args
def run_parallel_in_threads(target, args_list):
    result = Queue.Queue()
    # wrapper to collect return value in a Queue
    def task_wrapper(*args):
        result.put(target(*args))
    threads = [threading.Thread(target=task_wrapper, args=args) for args in args_list]
    for t in threads:
        t.start()
    for t in threads:
        t.join()
    return result

def dummy_task(n):
    for i in xrange(n):
        time.sleep(0.1)
    return n

# below is the application code
urls = [
    ('http://www.google.com/',),
    ('http://www.lycos.com/',),
    ('http://www.bing.com/',),
    ('http://www.altavista.com/',),
    ('http://achewood.com/',),
]

def fetch(url):
    return urllib2.urlopen(url).read()

run_parallel_in_threads(fetch, urls)

如您所见，特定于应用程序的代码只有 3 行，如果您有攻击性，可以将其折叠为 1 行。我认为没有人可以证明他们声称这是复杂且不可维护的。

不幸的是，这里发布的大多数其他线程代码都有一些缺陷。他们中的许多人进行主动轮询以等待代码完成。 join()是同步代码的更好方法。我认为到目前为止，这段代码已经改进了所有线程示例。

保持连接

如果您的所有 URL 都指向同一服务器，WoLpH 关于使用保持事件连接的建议可能非常有用。

扭曲

Aaron Gallagher 是 twisted 的粉丝框架，他敌视任何建议线程的人。不幸的是，他的许多说法都是错误信息。例如，他说“-1 用于建议线程。这是 IO 绑定(bind)的；线程在这里没用。”这与证据相反，因为 Nick T 和我都证明了使用线程的速度增益。事实上，I/O 密集型应用程序从使用 Python 的线程中获益最多(对比 CPU 密集型应用程序没有任何好处)。 Aaron 对线程的误导性批评表明，他对并行编程总体上感到相当困惑。

正确工作的正确工具

我很清楚与使用线程、python、异步 I/O 等进行并行编程有关的问题。每种工具都有其优点和缺点。对于每种情况，都有一个合适的工具。我不反对扭曲(虽然我自己没有部署一个)。但我不相信我们可以断然说线程是坏的，扭曲在所有情况下都是好的。

例如，如果 OP 的要求是并行获取 10,000 个网站，则异步 I/O 将是首选。线程不会被占用(除非可能使用无堆栈 Python)。

Aaron 对线程的反对主要是概括。他没有意识到这是一项微不足道的并行化任务。每个任务都是独立的，不共享资源。所以他的大部分攻击都不适用。

鉴于我的代码没有外部依赖，我将它称为正确的工具，用于正确的工作。

性能

我想大多数人都会同意这个任务的性能在很大程度上取决于网络代码和外部服务器，而平台代码的性能应该可以忽略不计。然而，Aaron 的基准测试显示，线程代码的速度提高了 50%。我认为有必要对这种明显的速度增益使用react。

在 Nick 的代码中，有一个明显的缺陷导致了效率低下。但是你如何解释我的代码 233ms 的速度增益？我认为即使是twisted 的粉丝也不会下结论将这归因于twisted 的效率。毕竟系统代码之外还有大量的变量，比如远程服务器的性能、网络、缓存、urllib2和twisted web客户端的差异实现等等。

只是为了确保 Python 的线程不会导致大量的低效率，我做了一个快速基准测试以生成 5 个线程，然后生成 500 个线程。我很自在地说产生 5 个线程的开销可以忽略不计，无法解释 233 毫秒的速度差异。

In [274]: %time run_parallel_in_threads(dummy_task, [(0,)]*5)
CPU times: user 0.00 s, sys: 0.00 s, total: 0.00 s
Wall time: 0.00 s
Out[275]: <Queue.Queue instance at 0x038B2878>

In [276]: %time run_parallel_in_threads(dummy_task, [(0,)]*500)
CPU times: user 0.16 s, sys: 0.00 s, total: 0.16 s
Wall time: 0.16 s

In [278]: %time run_parallel_in_threads(dummy_task, [(10,)]*500)
CPU times: user 1.13 s, sys: 0.00 s, total: 1.13 s
Wall time: 1.13 s       <<<<<<<< This means 0.13s of overhead

对我的并行提取的进一步测试表明，在 17 次运行中，响应时间存在巨大差异。 (不幸的是，我没有去验证 Aaron 的代码)。

0.75 s
0.38 s
0.59 s
0.38 s
0.62 s
1.50 s
0.49 s
0.36 s
0.95 s
0.43 s
0.61 s
0.81 s
0.46 s
1.21 s
2.87 s
1.04 s
1.72 s

我的测试不支持 Aaron 的结论，即线程在可测量的范围内始终比异步 I/O 慢。鉴于涉及的变量数量，我不得不说这不是衡量异步 I/O 和线程之间系统性能差异的有效测试。