金融数据获取(二）：多进程下的性能压力测试（下）

摘要：  

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

2：本文是上期文章 "搭上多进程并行的高速路" 2.1的补充内容，文章链接：(74条消息) 金融数据获取(二）：搭上多进程并行的高速路_simon1223z的博客-CSDN博客https://blog.csdn.net/simon1223z/article/details/120440536

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的工作基本都在频繁开启和关闭进程，运行时间随着线程增加而线性增加，也可以说是此时的效率随线程的增加而线性递减。

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

图七：线程数量（个）与运行时间（秒）散点分布