金融数据获取:多进程下的性能压力测试

摘要:  

1:本文将采用多进程对计算机性能进行压力测试,最后勾勒出进程数量与效率间的关系;

2:本文是上期文章 "搭上多进程并行的高速路" 2.1的补充内容,文章链接:金融数据获取:搭上多进程并行的高速路

3:开发环境选择了Pycharm,所有程序均基于python3.8;

4:本文依旧是基于干货的分享;

        由于是补充内容,我们直接开门见山,在上一篇文章中笔者指出:”在电脑性能允许的范围下,进程数与爬取效率间大致呈现正相关关系,但随着进程数的递增将出现边际递减,到某个阶段超出电脑负荷时开始边际为负。” 本文将设置压力条件,通过一个简单的压力测试具体解答进程数量与效率间的关系,并且笔者将展示CPU与进程运行状态。


目录

一、前提条件

1.1 主要硬件及软件条件

1.2 压力条件

二、开始运行

三、分析与结论


一、前提条件

1.1 主要硬件及软件条件

        由于电脑间性能差异很大,先设置好程序运行的前提条件以保证结果的准确性

        1):笔者使用自己的一台老爷机进行测试,主要配置如下:

处理器 Intel(R) Core(TM) i5-3340M CPU @ 2.70GHz  (四核)
机带 RAM 8.00 GB (7.90 GB 可用)
系统类型 Win 10 64 位操作系统, 基于 x64 的处理器
硬盘东芝固态加机械硬盘

       2): 程序运行前已经关闭大部分软件

         3):网络通过无线400兆WiFi接入,网络状态稳定

1.2 压力条件

        为了勾勒出进程与效率间的关系,笔者打算从单进程一直测试到200进程,只要将上期文章中的代码进行遍历就可以达到该效果。毕竟要遍历很多次,这么长的运行时间笔者还希望将结果存进CSV中方便以后查看。

        于是对上期爬虫代码的主程序作出如下修改:

if __name__ == '__main__':
    m = multiprocessing.Manager()
    sl = m.list()
    num , timer = [], [] # 用来存进程数,运行时间
    for a in range(1,200,2): # 设置步长,没必要拿那么密集的数据,只要观察大致趋势就好了
        try:
            start = time.time()
            devisor, process_pool, stock_list = len(url_list) // a, [], []
            for i in range(0, a):
                t1 = multiprocessing.Process(target=craw, args=(url_list[devisor * i:devisor * (i + 1)],  sl),
                                         name="task{}".format(i))
                process_pool.append(t1)
                t1.start()
            for i in process_pool:
                i.join()
            num.append(a)

            end = time.time()
            print("总列表", sl, len(sl), id(sl))

            print(a,"进程执行时间", end - start)
            t = end - start
            timer.append(t)
        except:
            continue
    time = {"number":num, "run_time":timer }
    df = pd.DataFrame(time)
    df.to_csv("path") # 自行设置存储路径

二、开始运行

        在只有单线程的状态下,可以看到CPU运行很轻松,中间出现的波峰系开启和关闭进程所致。

图一:单进程下CPU运行状态

         继续遍历更多进程,当开启10个进程时,CPU开始出现大幅波动,图二中CPU利用率出现满载并且持续了一段时间,满载这段时间系开启和关闭进程所致。

图二:10进程下CPU运行状态

          继续遍历,当进程数达到30个时,笔者发现CPU开始主动降频了,开启和关闭进程时不再满载运行,系进程数增多,CPU开启和关闭进程的时间拉长。

图三:30进程下CPU运行状态


 

         继续毫无人性的压榨,下图分别为43进程和60进程截图,可以明显看到,开启和关闭进程所消耗的时间继续增大,波谷时间持续变小。当达到80进程时CPU几乎完全处于不断开启和关闭进程的状态。

图四:43进程(上)、60进程(中)和80进程(下)

 

 

        来一张夸张的180进程,实验进行到现在对这台脆弱的老爷机可以说是毫无人性了。

图五:180进程

 

         当遍历到执行190+进程,电脑基本处于瓦特状态,笔者都不敢截图了,一碰怕脆弱的系统崩溃。。这里有意思的是资源监视器上显示只有196个进程在活动,难不成这时候只有一个进程在支持系统运行?显然CPU应该是在后台进行了调配,而笔者爬取到的也都变成了空列表,就暂时把它解释成处于崩溃边缘吧,有谁知道背后原理的也欢迎在文末留言。

图六:遍历195线程时 

        程序运行结束,所有进程也都关闭了,电脑起死回生。同一时间笔者也拿到了CSV中的进程运行数据。

 

         

三、分析与结论

        运行数据主要记录了线程运行时间及线程数量,将数据展示如图七所示。相比但进程的80几秒,多线程显著的提高了运行效率,但随着线程数的提高,运行效率的提高并不显著。在线程数超过60 后CPU的工作基本都在频繁开启和关闭进程,运行时间随着线程增加而线性增加,也可以说是此时的效率随线程的增加而线性递减。

        由此可见,只有合理运用多进程才能提高效率

图七:线程数量(个)与运行时间(秒)散点分布

  • 3
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Simon Cao

创作不易,您的鼓励将是我的动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值