测试平台系列(43) aiohttp初体验

简介: aiohttp初体验

大家好,我是米洛,一位测试球迷!

如果阅读完毕后想和作者有更多交流,可以点击阅读原文找到底部评论区,给作者留言啦!

本文如果有错误,请及时发消息指正,有错漏我就删了以免误导大家!)

回顾

上回我们搞定了一整套流程,关于数据构造器的,今天我们来引入aiohttp。

在此之前我们简单说下预备知识:

Python的异步

其实写这篇文章的时候我内心是很纠结的,因为我其实也不算太明白里头的门路。虽然看了很多文章,但感觉写起异步的代码还是会比较费劲。

大家可以去搜索一些异步的文章,让我讲我还讲的不太透彻。

参考:

举个鲜活的例子


比如去买早餐并打包回家。我早上要吃一碗汤面+一杯豆浆+2个油饼。很可惜的是,这3个摊子虽然在一起,但是都是要排队的。

Python同步场景:

  1. 我买豆浆,等豆浆打好。
  2. 我买汤面,等汤面做好。
  3. 我买油饼,等油饼做好。

这就是一个个的同步任务,我只有做完了一个才能去做下一个。耗费总时间为3个步骤的耗时总和。

Python异步(asyncio)就类似这样的场景:

  1. 我先和老板说我要一碗汤面,这时候老板正在制作中或者排队中,但是他已经在处理我的需求了
  2. 我再去和包子铺的人说来杯豆浆
  3. 最后去油货铺子跟老板说要2个油饼

如果1,2,3里面任意一个好了,都会通知我去拿,这样虽然我还是一个人,但是我效率更高了。耗时总时间仅仅是一个线程内部的切换+最慢的那个时间。

常规多线程场景:

  1. 我哥去帮我买豆浆,等豆浆打好。
  2. 我姐去帮我买汤面,等汤面做好。
  3. 我自己去买油饼,等油饼做好。

等于是派出了3个人,去做3件事情。每件事情之间没有啥关系,耗费总时间以最慢的那个为准

我们重点讲讲asyncio做的事情,其实他是有一个event_loop,你可以理解为管理线程中事件的东西没,它帮助我们进行事情的切换。

比如上面说的,跟老板说完买豆浆了,老板在那忙活了,这时候你就该让出资源,切换到下一个事件(去买汤面),最后豆浆做好了,你怎么知道去拿呢?也是这个event_loop通知你,让你能够回去拿豆浆。

大致原理就是这样,我们还不需要掌握怎么切换事件,我们只需要告诉event_loop,我们的买豆浆是一个异步方法,其中等待老板把包子做好的时间,可以让出资源给其他事件。

熟悉async和await

当我们给一个方法,加上了async关键字之后,它就变成了一个异步方法,而我们的await关键字,只能在async方法中使用,意思是它让出对当前线程的控制权,可以让线程去执行其他内容。

一般来说我们自己编写的方法,不是在方法前加个async,调用方法的时候加个await就行得通的。比如我们用requests,他里头全是同步方法,我们就算给了async和await也没什么作用,所以我们需要一个异步http请求库。

以上面的例子来说,如果我去油饼摊,老板说不许走,马上就好了。那我就只能留在那边,先老老实实把油饼买了再去下一个地方。

不知道这样说,是不是比较好理解。

aiohttp

aiohttp是一个异步的http框架,你可以把它理解为异步版的requests。我们还有许多这样的库比如aiofile,这些改造后的异步类库,以后会有更多的异步类库出现。

为什么我们要这么麻烦呢?是request不香了吗?其实也不是。Python一直被人诟病执行慢,这点在我上家公司使用时深有感触

曾经的难题


有那么一个需求,当时是从别人的接口里面抓取公司所有服务的数据,并写入到我们本地数据库。大概几千个app,同步一次那是慢的很啊,写伪代码就是:


for i in range(100):
  r = requests.get("xxx")
  data = r.json()
  cursor.execute("insert into xxx....")

慢的原因主要是http过程比较耗时,我们在等待响应的时候,其他的任务没有同时进行。

就好像这里有100亩田,就1个人种,等他种完田都猴年马月了。有人会问,你咋不用threading,多开几个线程,也就是多叫几个人,比如叫100个人,一起种,那不就快了吗?

我也想,可是GIL实力不允许啊,虽然我没有亲自这样做,但是结局应该是可以预料的。如果有兴趣的话,我以后可能会做这样的测试

那么会有人问,那你怎么搞定的?其实我是用了go去调整了代码,用几十个goroutine去完成了这个事情,速度大概快了个几百倍,一小会就同步完了

试试aiohttp


想到了上述的难题,又想起自己以后要批量跑用例。所以我不禁神伤,决定尝试一下aiohttp吧。

在此之前,我也只是听过它的大名,并无实际经验。

相关文档: https://docs.aiohttp.org/en/stable/

28.jpg

看看demo

改造之前的HttpClient.py


我们新建一个文件,叫AsyncHttpClient.py

  • 编写好构造函数

29.jpg

image

和以前几乎一样,多了一个timeout,因为aiohttp的timeout不是int/float类型,而是aiohttp.ClientTimeout.

  • 编写get_cookie方法


def get_cookie(self, session):
    cookies = session.cookie_jar.filter_cookies(self.url)
    return {k: v.value for k, v in cookies.items()}

通过session中的cookie_jar去获取cookie.

  • 编写获取resp方法

30.jpg

当response是json我们给他反序列化为Python对象,否则返回字符串

  • 编写collect方法
    其实这个方法就是组装了请求的一些数据。

31.jpg

和之前的比较类似

  • 编写invoke方法
    (出于跟风,我在很多rpc框架都看到类似这样的叫法)

32.jpg

image

首先用async with获取了一个session,注意这里戴上了Cookie。其他地方没有什么区别,并额外计算了请求时间。

如何使用


33.jpg

image

先看看我们http测试这个接口,将方法改为async,request部分改为AsyncRequest,并await invoke返回的内容。

试试request请求


34.jpg

点亮,完美

小测试代码



import asyncio
import time
import aiohttp
import requests
url = "https://www.baidu.com"
async def fetchBaidu():
    async with aiohttp.ClientSession() as session:
        resp = await session.get(url)
        text = await resp.text(encoding='utf-8')
        print(text.split("\n")[0])
async def main():
    start = time.time()
    await asyncio.gather(*(fetchBaidu() for _ in range(200)))
    print("花费时间:", time.time() - start)
def main2():
    start = time.time()
    session = requests.Session()
    for i in range(200):
        r = session.get(url)
        print(r.text.split("\n")[0])
    print("花费时间:", time.time() - start)
if __name__ == "__main__":
    asyncio.run(main())
    # main2()

目前是200次测试,这是aiohttp的速度:

35.jpg

aiohttp

36.jpg

普通的requests

循环太多的话,百度有点不开心了

今天的内容就分享到这里了,大家可以拿着这个脚本玩玩,试试看,看看aiohttp屌在哪里!



相关文章
|
14天前
|
Kubernetes 测试技术 Perl
混沌测试平台 Chaos Mesh
混沌测试平台 Chaos Mesh
34 1
|
1月前
|
传感器 数据采集 监控
LabVIEW电池管理系统测试平台
LabVIEW电池管理系统测试平台
28 4
|
6天前
|
运维 Kubernetes 监控
|
2月前
|
人工智能 分布式计算 DataWorks
首批!阿里云 MaxCompute 完成中国信通院数据智能平台专项测试
2024年5月31日,在中国信通院组织的首批数据智能平台专项测试中,阿里云数据智能平台解决方案(MaxCompute、DataWorks、PAI)顺利完成测试。
166 5
首批!阿里云 MaxCompute 完成中国信通院数据智能平台专项测试
|
1月前
|
传感器 存储 数据采集
LabVIEW阀性能测试平台
LabVIEW阀性能测试平台
24 0
|
2月前
|
消息中间件 Kubernetes Kafka
AutoMQ 自动化持续测试平台技术内幕
Marathon 是一个针对流系统 AutoMQ 的自动化持续测试平台,旨在在模拟生产环境和各种故障场景中验证 SLA 的可靠性。设计原则包括易拓展、可观测和低成本。平台采用分布式架构,Controller 负责资源管理和任务编排,动态调整 Worker 数量和配置,而 Worker 是无状态的,用于生成负载和上报数据。系统基于 K8S,利用服务发现、事件总线和 Spot 实例降低成本并提高弹性。测试场景以代码形式描述,支持不同流量模型和断言,提供丰富的可观测性和告警功能。未来,Marathon 有望泛化为适用于各种分布式系统的测试平台。
38 0
AutoMQ 自动化持续测试平台技术内幕
|
2月前
|
jenkins Java 测试技术
电商返利平台的测试与持续集成
电商返利平台的测试与持续集成
|
3月前
|
数据挖掘 测试技术 网络安全
LabVIEW开发卫星测试平台
LabVIEW开发卫星测试平台
39 3
|
3月前
|
消息中间件 测试技术 Linux
linux实时操作系统xenomai x86平台基准测试(benchmark)
本文是关于Xenomai实时操作系统的基准测试,旨在评估其在低端x86平台上的性能。测试模仿了VxWorks的方法,关注CPU结构、指令集等因素对系统服务耗时的影响。测试项目包括信号量、互斥量、消息队列、任务切换等,通过比较操作前后的时戳来测量耗时,并排除中断和上下文切换的干扰。测试结果显示了各项操作的最小、平均和最大耗时,为程序优化提供参考。注意,所有数据基于特定硬件环境,测试用例使用Alchemy API编写。
900 0
linux实时操作系统xenomai x86平台基准测试(benchmark)
|
3月前
|
算法 物联网 5G
LabVIEW开发最小化5G系统测试平台
LabVIEW开发最小化5G系统测试平台
45 0

热门文章

最新文章