本文例項講述了Python aiohttp百萬併發極限測試。分享給大家供大家參考，具體如下：

本文將測試python aiohttp的極限，同時測試其效能表現，以分鐘發起請求數作為指標。大家都知道，當應用到網路操作時，非同步的程式碼表現更優秀，但是驗證這個事情，同時搞明白非同步到底有多大的優勢以及為什麼會有這樣的優勢仍然是一件有趣的事情。為了驗證，我將發起1000000請求，用aiohttp客戶端。aiohttp每分鐘能夠發起多少請求？你能預料到哪些異常情況以及崩潰會發生，當你用比較粗糙的指令碼去發起如此大量的請求？面對如此大量的請求，哪些主要的陷阱是你需要去思考的？

初識 asyncio/aiohttp

非同步程式設計並不簡單。相比平常的同步程式設計，你需要付出更多的努力在使用回撥函式，以事件以及事件處理器的模式進行思考。同時也是因為asyncio相對較新，相關的教程以及部落格還很少的緣故。官方文件非常簡陋，只有最基本的範例。在我寫本文的時候，Stack Overflow上面，只有410個與asyncio相關的話題（相比之下，twisted相關的有2585）。有個別關於asyncio的不錯的部落格以及文章，比如這個、這個、這個，或者還有這個以及這個。

簡單起見，我們先從基礎開始 —— 簡單HTTP hello world —— 發起GET請求，同時獲取一個單獨的HTTP響應。

同步模式，你這麼做：

import requests
def hello()
   return requests.get("http://httpbin.org/get")
print(hello())

接著我們使用aiohttp：

#!/usr/local/bin/python3.5
import asyncio
from aiohttp import ClientSession
async def hello():
  async with ClientSession() as session:
    async with session.get("http://httpbin.org/headers") as response:
      response = await response.read()
      print(response)
loop = asyncio.get_event_loop()
loop.run_until_complete(hello())

好吧，看上去僅僅一個簡單的任務，我寫了很多的程式碼……那裡有“async def”、“async with”、“await”—— 看上去讓人迷惑，讓我們嘗試弄懂它們。

你使用async以及await關鍵字將函式非同步化。在hello()中實際上有兩個非同步操作：首先非同步獲取相應，然後非同步讀取響應的內容。

Aiohttp推薦使用ClientSession作為主要的介面發起請求。ClientSession允許在多個請求之間儲存cookie以及相關物件資訊。Session(會話)在使用完畢之後需要關閉，關閉Session是另一個非同步操作，所以每次你都需要使用async with關鍵字。

一旦你建立了客戶端session，你可以用它發起請求。這裡是又一個非同步操作的開始。上下文管理器的with語句可以保證在處理session的時候，總是能正確的關閉它。

要讓你的程式正常的跑起來，你需要將他們加入事件迴圈中。所以你需要建立一個asyncio loop的例項， 然後將任務加入其中。

看起來有些困難，但是隻要你花點時間進行思考與理解，就會有所體會，其實並沒有那麼複雜。

訪問多個連結

現在我們來做些更有意思的事情，順序訪問多個連結。

同步方式如下：

for url in urls:
  print(requests.get(url).text)

很簡單。不過非同步方式卻沒有這麼容易。所以任何時候你都需要思考，你的處境是否有必要用到非同步。如果你的app在同步模式工作的很好，也許你並不需要將之遷移到非同步方式。如果你確實需要非同步方式，這裡會給你一些啟示。我們的非同步函式hello()還是保持原樣，不過我們需要將之包裝在asyncio的Future物件中，然後將Future物件列表作為任務傳遞給事件迴圈。

loop = asyncio.get_event_loop()
tasks = [] # I'm using test server localhost,but you can use any url
url = "http://localhost:8080/{}"
for i in range(5):
  task = asyncio.ensure_future(hello(url.format(i)))
  tasks.append(task)
loop.run_until_complete(asyncio.wait(tasks))

現在假設我們想獲取所有的響應，並將他們儲存在同一個列表中。目前，我們沒有儲存響應內容，僅僅只是列印了他們。讓我們返回他們，將之儲存在一個列表當中，最後再打印出來。

為了達到這個目的，我們需要修改一下程式碼：

#!/usr/local/bin/python3.5
import asyncio
from aiohttp import ClientSession
async def fetch(url):
  async with ClientSession() as session:
   async with session.get(url) as response:
     return await response.read()
async def run(loop,r):
  url = "http://localhost:8080/{}"
  tasks = []
  for i in range(r):
    task = asyncio.ensure_future(fetch(url.format(i)))
    tasks.append(task)
    responses = await asyncio.gather(*tasks)
    # you now have all response bodies in this variable
    print(responses)
def print_responses(result):
  print(result)
loop = asyncio.get_event_loop()
future = asyncio.ensure_future(run(loop,4))
loop.run_until_complete(future)

注意asyncio.gather()的用法，它蒐集所有的Future物件，然後等待他們返回。

常見錯誤

現在我們來模擬真實場景，去除錯一些錯誤，作為演示範例。

看看這個：

# WARNING! BROKEN CODE DO NOT COPY PASTE
async def fetch(url):
  async with ClientSession() as session:
   async with session.get(url) as response:
     return response.read()

如果你對aiohttp或者asyncio不夠了解，即使你很熟悉Python，這段程式碼也不好debug。

上面的程式碼產生如下輸出：

pawel@pawel-VPCEH390X ~/p/l/benchmarker> ./bench.py
[<generator object ClientResponse.read at 0x7fa68d465728>,
<generator object ClientResponse.read at 0x7fa68cdd9468>,
<generator object ClientResponse.read at 0x7fa68d4656d0>,
<generator object ClientResponse.read at 0x7fa68cdd9af0>]

發生了什麼？你期待獲得響應物件，但是你得到的是一組生成器。怎麼會這樣？

我之前提到過，response.read()是一個非同步操作，這意味著它不會立即返回結果，僅僅返回生成器。這些生成器需要被呼叫跟執行，但是這並不是預設行為。在Python34中加入的yield from以及Python35中加入的await便是為此而生。它們將迭代這些生成器。以上程式碼只需要在response.read()前加上await關鍵字即可修復。如下：

  # async operation must be preceded by await
  return await response.read()
  # NOT: return response.read()

我們看看另一個例子。

# WARNING! BROKEN CODE DO NOT COPY PASTE
async def run(loop,r):
  url = "http://localhost:8080/{}"
  tasks = []
  for i in range(r):
    task = asyncio.ensure_future(fetch(url.format(i)))
    tasks.append(task)
    responses = asyncio.gather(*tasks)
    print(responses)

輸出結果如下：

pawel@pawel-VPCEH390X ~/p/l/benchmarker> ./bench.py
<_GatheringFuture pending>
Task was destroyed but it is pending!
task: <Task pending coro=<fetch() running at ./bench.py:7>
wait_for=<Future pending cb=[Task._wakeup()]>
cb=[gather.<locals>._done_callback(0)()
at /usr/local/lib/python3.5/asyncio/tasks.py:602]>
Task was destroyed but it is pending!
task: <Task pending coro=<fetch() running at ./bench.py:7>
　　wait_for=<Future pending cb=[Task._wakeup()]>
　　cb=[gather.<locals>._done_callback(1)()
　　at /usr/local/lib/python3.5/asyncio/tasks.py:602]>
Task was destroyed but it is pending!
task: <Task pending coro=<fetch() running at ./bench.py:7>
　　wait_for=<Future pending cb=[Task._wakeup()]>
　　cb=[gather.<locals>._done_callback(2)()
　　at /usr/local/lib/python3.5/asyncio/tasks.py:602]>
Task was destroyed but it is pending!
task: <Task pending coro=<fetch() running at ./bench.py:7>
　　wait_for=<Future pending cb=[Task._wakeup()]>
　　cb=[gather.<locals>._done_callback(3)()
　　at /usr/local/lib/python3.5/asyncio/tasks.py:602]>

發生了什麼？檢視本地日誌，你會發現沒有任何請求到達伺服器，實際上沒有任何請求發生。列印資訊首先列印<_Gathering pending>物件，然後警告等待的任務被銷燬。又一次的，你忘記了await。

修改

responses = asyncio.gather(*tasks)

到

responses = await asyncio.gather(*tasks)

即可解決問題。

經驗：任何時候，你在等待什麼的時候，記得使用await。

同步 vs 非同步

重頭戲來了。我們來驗證非同步是否值得（編碼麻煩）。看看同步與非同步（client）效率上的區別。非同步每分鐘能夠發起多少請求。

為此，我們首先配置一個非同步的aiohttp伺服器端。這個服務端將獲取全部的html文字， 來自Marry Shelley的Frankenstein。在每個響應中，它將新增隨機的延時。有的為0，最大值為3s。類似真正的app。有些app的響應延時為固定值，一般而言，每個響應的延時是不同的。

伺服器程式碼如下：

#!/usr/local/bin/python3.5
import asyncio
from datetime import datetime
from aiohttp import web
import random
# set seed to ensure async and sync client get same distribution of delay values
# and tests are fair random.seed(1)
async def hello(request):
  name = request.match_info.get("name","foo")
  n = datetime.now().isoformat()
  delay = random.randint(0,3)
  await asyncio.sleep(delay)
  headers = {"content_type": "text/html","delay": str(delay)}
  # opening file is not async here,so it may block,to improve
  # efficiency of this you can consider using asyncio Executors
  # that will delegate file operation to separate thread or process
  # and improve performance
  # https://docs.python.org/3/library/asyncio-eventloop.html#executor
  # https://pymotw.com/3/asyncio/executors.html
  with open("frank.html","rb") as html_body:
     print("{}: {} delay: {}".format(n,request.path,delay))
     response = web.Response(body=html_body.read(),headers=headers)
     return response
app = web.Application()
app.router.add_route("GET","/{name}",hello)
web.run_app(app)

同步客戶端程式碼如下：

import requests
r = 100
url = "http://localhost:8080/{}"
for i in range(r):
  res = requests.get(url.format(i))
 delay = res.headers.get("DELAY")
 d = res.headers.get("DATE")
 print("{}:{} delay {}".format(d,res.url,delay))

在我的機器上，上面的程式碼耗時2分45s。而非同步程式碼只需要3.48s。

有趣的是，非同步程式碼耗時無限接近最長的延時（server的配置）。如果你觀察列印資訊，你會發現非同步客戶端的優勢有多麼巨大。有的響應為0延遲，有的為3s。同步模式下，客戶端會阻塞、等待，你的機器什麼都不做。非同步客戶端不會浪費時間，當有延遲發生時，它將去做其他的事情。在日誌中，你也會發現這個現象。首先是0延遲的響應，然後當它們到達後，你將看到1s的延遲，最後是最大延遲的響應。

極限測試

現在我們知道非同步表現更好，讓我們嘗試去找到它的極限，同時嘗試讓它崩潰。我將傳送1000非同步請求。我很好奇我的客戶端能夠處理多少數量的請求。

> time python3 bench.py
2.68user 0.24system 0:07.14elapsed 40%CPU
(0avgtext+0avgdata 53704maxresident)
k 0inputs+0outputs (0major+14156minor)pagefaults 0swaps

1000個請求，花費了7s。相當不錯的成績。然後10K呢？很不幸，失敗了：

responses are <_GatheringFuture finished exception=
　　ClientOSError(24,'Cannot connect to host localhost:8080 ssl:
　　False [Can not connect to localhost:8080 [Too many open files]]')>
Traceback (most recent call last):
File "/home/pawel/.local/lib/python3.5/site-packages/aiohttp/connector.py",line 581,in _create_connection
File "/usr/local/lib/python3.5/asyncio/base_events.py",line 651,in create_connection
File "/usr/local/lib/python3.5/asyncio/base_events.py",line 618,in create_connection
File "/usr/local/lib/python3.5/socket.py",line 134,in __init__ OS
Error: [Errno 24] Too many open files

這樣不大好，貌似我倒在了10K connections problem面前。

traceback顯示，open files太多了，可能代表著open sockets太多。為什麼叫檔案？Sockets（套接字）僅僅是檔案描述符，作業系統有數量的限制。多少才叫太多呢？我檢視Python原始碼，然後發現這個值為1024.怎麼樣繞過這個問題？一個粗暴的辦法是增加這個數值，但是聽起來並不高明。更好的辦法是，加入一些同步機制，限制併發數量。於是我在asyncio.Semaphore()中加入最大任務限制為1000.

修改客戶端程式碼如下：

# modified fetch function with semaphore
import random
import asyncio
from aiohttp import ClientSession
async def fetch(url):
  async with ClientSession() as session:
    async with session.get(url) as response:
    　delay = response.headers.get("DELAY")
    　date = response.headers.get("DATE")
    　print("{}:{} with delay {}".format(date,response.url,delay))
    　return await response.read()
async def bound_fetch(sem,url):
  # getter function with semaphore
  async with sem:
  　await fetch(url)
  async def run(loop,r):
  　url = "http://localhost:8080/{}"
  　tasks = []
  　# create instance of Semaphore
  　sem = asyncio.Semaphore(1000)
  　for i in range(r):
  　  # pass Semaphore to every GET request
  　  task = asyncio.ensure_future(bound_fetch(sem,url.format(i)))
  　  tasks.append(task)
  　  responses = asyncio.gather(*tasks)
await responses number = 10000
loop = asyncio.get_event_loop()
future = asyncio.ensure_future(run(loop,number))
loop.run_until_complete(future)

現在，我們可以處理10k連結了。這花去我們23s，同時返回了一些異常。不過不管怎樣，相當不錯的表現。

那100K呢？這個任務讓我的機器很吃力，不過驚奇的是，它工作的很好。伺服器的表現相當穩定，雖然記憶體佔用很高，然後cpu佔用一直維持在100%左右。讓我覺得有趣的是，伺服器佔用的cpu明顯小於client。這是ps的回顯：

pawel@pawel-VPCEH390X ~/p/l/benchmarker> ps ua | grep python
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
pawel 2447 56.3 1.0 216124 64976 pts/9 Sl+ 21:26 1:27 /usr/local/bin/python3.5 ./test_server.py
pawel 2527 101 3.5 674732 212076 pts/0 Rl+ 21:26 2:30 /usr/local/bin/python3.5 ./bench.py

最終因為某些原因，執行5分鐘過後，它崩潰了。它生成了接近100K行的輸出，所以很難定位traceback，好像某些響應沒有正常關閉。具體原因不太確定。(client or server error)

一段時間的滾動以後，我找到了這個異常，在client日誌中。

File "/usr/local/lib/python3.5/asyncio/futures.py",line 387,in __iter__
return self.result() # May raise too.
File "/usr/local/lib/python3.5/asyncio/futures.py",line 274,in result
raise self._exception
File "/usr/local/lib/python3.5/asyncio/selector_events.py",line 411,in _sock_connect
sock.connect(address) OS
Error: [Errno 99] Cannot assign requested address

我不太確定這裡發生了什麼。我初始的猜測是測試伺服器掛掉了。一個讀者提出：這個異常的發生原因是作業系統的可用埠耗盡。之前我限制了併發連線數最大為1k，可能有些sockets仍然處在closing狀態，系統核心無法使用才導致這個問題。

已經很不錯了，不是嗎？100k耗時5分鐘。相當於一分鐘20k請求數。

最後我嘗試1M連線數。我真怕我的筆記本因為這個爆炸^_^.我特意將延遲降低為0到1s之間。最終耗時52分鐘。

1913.06user 1196.09system 52:06.87elapsed 99%CPU
(0avgtext+0avgdata 5194260maxresident)k 265144
inputs+0outputs (18692major+2528207minor)
pagefaults 0swaps

這意味著，我們的客戶端每分鐘傳送了19230次請求。還不錯吧？注意客戶端的效能被伺服器限制了，好像伺服器端崩潰了好幾次。

最後

如你所見，非同步HTTP客戶端相當強大。發起1M請求不是那麼困難，同時相比同步模式，優勢巨大。

我好奇對比其他的語言或者非同步框架，其表現如何？可能在以後某個時候，我將對比Twisted Treq跟aiohttp。然後，其他的非同步庫(其他語言)能夠支援到多少併發？比如：某些Java 非同步框架？或者C++框架？或者某些Rust HTTP客戶端？

更多關於Python相關內容感興趣的讀者可檢視本站專題：《Python程序與執行緒操作技巧總結》、《Python資料結構與演算法教程》、《Python函式使用技巧總結》、《Python字串操作技巧彙總》、《Python入門與進階經典教程》、《Python+MySQL資料庫程式設計入門教程》及《Python常見資料庫操作技巧彙總》

希望本文所述對大家Python程式設計有所幫助。