gpt4 book ai didi

python - 为什么 asyncio 不总是使用执行器?

转载 作者:太空宇宙 更新时间:2023-11-03 13:07:38 24 4
gpt4 key购买 nike

我必须发送很多 HTTP 请求,一旦所有请求都返回,程序才能继续。听起来非常适合 asyncio。有点天真,我将对 requests 的调用包装在 async 函数中,并将它们交给 asyncio。这是行不通的。

在网上搜索后,找到了两种解决方案:

  • 使用类似aiohttp 的库,它与 asyncio
  • 配合使用
  • 将阻塞代码包装在对 run_in_executor 的调用中

为了更好地理解这一点,我编写了一个小型基准测试。服务器端是一个 flask 程序,在响应请求之前等待 0.1 秒。

from flask import Flask
import time

app = Flask(__name__)


@app.route('/')
def hello_world():
time.sleep(0.1) // heavy calculations here :)
return 'Hello World!'


if __name__ == '__main__':
app.run()

客户是我的标杆

import requests
from time import perf_counter, sleep

# this is the baseline, sequential calls to requests.get
start = perf_counter()
for i in range(10):
r = requests.get("http://127.0.0.1:5000/")
stop = perf_counter()
print(f"synchronous took {stop-start} seconds") # 1.062 secs

# now the naive asyncio version
import asyncio
loop = asyncio.get_event_loop()

async def get_response():
r = requests.get("http://127.0.0.1:5000/")

start = perf_counter()
loop.run_until_complete(asyncio.gather(*[get_response() for i in range(10)]))
stop = perf_counter()
print(f"asynchronous took {stop-start} seconds") # 1.049 secs

# the fast asyncio version
start = perf_counter()
loop.run_until_complete(asyncio.gather(
*[loop.run_in_executor(None, requests.get, 'http://127.0.0.1:5000/') for i in range(10)]))
stop = perf_counter()
print(f"asynchronous (executor) took {stop-start} seconds") # 0.122 secs

#finally, aiohttp
import aiohttp

async def get_response(session):
async with session.get("http://127.0.0.1:5000/") as response:
return await response.text()

async def main():
async with aiohttp.ClientSession() as session:
await get_response(session)

start = perf_counter()
loop.run_until_complete(asyncio.gather(*[main() for i in range(10)]))
stop = perf_counter()
print(f"aiohttp took {stop-start} seconds") # 0.121 secs

因此,使用 asyncio 的直观实现不会处理阻塞 io 代码。但是如果你正确使用asyncio,它和特殊的aiohttp框架一样快。 coroutines and tasks 的文档真的不要提这个。只有当你阅读了loop.run_in_executor() ,它说:

# File operations (such as logging) can block the
# event loop: run them in a thread pool.

我对这种行为感到惊讶。 asyncio 的目的是加速阻塞 io 调用。为什么需要额外的包装器 run_in_executor 来执行此操作?

aiohttp 的全部卖点似乎是对asyncio 的支持。但据我所知,requests 模块工作得很好——只要你把它包装在一个执行器中。是否有理由避免在执行程序中包装某些东西?

最佳答案

But as far as I can see, the requests module works perfectly - as long as you wrap it in an executor. Is there a reason to avoid wrapping something in an executor ?

Running code in executor 表示在OS threads中运行.

aiohttp 和类似的库允许在没有操作系统线程的情况下运行非阻塞代码,仅使用协程。

如果您没有太多工作,操作系统线程和协程之间的差异并不显着,尤其是与瓶颈 - I/O 操作相比。但是一旦你有很多工作,你会注意到由于昂贵的 context switching,操作系统线程的性能相对较差。 .

例如,当我将您的代码更改为time.sleep(0.001)range(100) 时,我的机器显示:

asynchronous (executor) took 0.21461606299999997 seconds
aiohttp took 0.12484742700000007 seconds

并且这种差异只会根据请求的数量而增加。

The purpose of asyncio is to speed up blocking io calls.

不,asyncio 的目的是提供方便的方式来控制执行流程。 asyncio 允许您选择流程的工作方式 - 基于协程和操作系统线程(当您使用执行器时)或纯协程(如 aiohttp 所做的)。

aiohttp 的目的是加快速度,它处理如上所示的任务:)

关于python - 为什么 asyncio 不总是使用执行器?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/53260688/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com