山西大同地图:C# 多线程料想

admin 4周前 (10-05) 科技 57 2

公司分配给我一个活,让我给Kong网关做一个获取设置的站点。Kong网关号称几万的QPS的神器,我有点慌,若是由于我的站点拖累了Kong我就是千古罪人。

配合Kong的站点必须要经由性能测试,在性能测试的时刻就发现个很有意思的征象,若是我用25条线程压我的站点,那么结果是这样的。

 

 若是我用50条线程去压站点,结果是这样的

 

 征象就是,我提高了并发数目,我的QPS实在并没有什么转变,然则我的单次平均响应时间缺提高了一倍。实在这种征象照样比较好注释的。首先,我们来领会一下,IIS的也许处置逻辑。

 

实在IIS维护了这么几个器械,首先一个是行列,用来提高服务器的同时处置请求数用的。这么说吧,假设我现在程序很原始很简陋,我一次只能处置一条请求,那么,我在处置一条请求的过程中,第二条请求过来了,那么这个时刻我显然不应该告诉他,我现在正忙,没空搭理他,而应该是告诉他,你先等会,我马上来处置你。让他等会,实在就是相当于把他放到行列里边,一会再来处置。

另外一个观点叫做,同时处置数。适才我的假设是我一次只能处置一条数据。然则我存在多个核,就算是一核在一个时间点上只能处置一条数据,那么,现在我机械是4核的,那么我最起码也应该能处置4条数据,假设现在一次性来了4条数据,那么这4条数据基本上可以以为是同时在处置的,然则若是同时来了8条数据,那么就是4条在处置,4条在守候。

现在来注释一下,为什么会泛起50并发比25并发,提升了守候时间,然则QPS并没有提高。我想可以这么注释,实在QPS在25并发的时刻已经接近于极限了,这个极限应该怎么算呢,也许就应该是1秒 * 同时处置数 / 每个请求的真实处置时间。可以看出来这个极限实在跟客户端的并发数没有什么直接联系。那么50并发的时刻,为什么守候的时间反而变长了呢?那是由于,客户端并发数大于服务器同时处置数的时刻,有一部门牢固数目的请求在请求行列里,他必须守候已经进入处置逻辑的部门处置完,然后再处置自己,以是就造成了QPS并没有提升然则响应时间变长的征象发生。

由于是这样的多倍叠加的模式,以是,有时刻,你会发现,你的接口,若是只是几毫秒响应的话,人人都很快。然则一旦你慢下来,响应时间是成指数级的增进。缘故原由也很简单,主要有以下几个。

  • 守候的行列边长了(由于前边处置的很慢,以是等的人越来越多)
  • 守候的单次边长了(然则变长的人不止是你自己呀,另有你守候的其他人)

这几个情形一综合那可不是乘法运算嘛,那可不就是指数级增添嘛。

 

提问,那么事实若干并发,才是最理想的状态呢?

之前思量这个问题的时刻,可能天经地义的以为,这个器械嘛,应该是跟CPU核数有关系,应该跟核数一样多就是最优解了吧。然则现实经常啪啪打脸。经由实测,一样平常是要比CPU核数若干不少才是CPU不累,处置效率很高的状态。那么为什么会泛起这种情形呢?我以为这个问题有点大,我们需要拆开来看。

 

1、一个焦点真的是一条线程执行的最快吗?

这个问题嘛,实在也对,也纰谬。说他对视由于,实在若是存在多条线程,那么多条线程之间切换的时刻,实在也挺消耗资源的。然则多线程的意义是什么呢?我以为这个问题也可以拆成两个问题。在拆问题之前先给先容两个观点。盘算密集型、IO密集型,盘算密集型就是你在做运算,加减乘除也好,比对也要,加密解密也好,这种主要依赖于CPU叫盘算密集型线程。若是你的线程大部门时间都消耗在了读取网络数据,读取内陆数据,或者驱动硬件守候返回这种情形叫做IO密集型。

1.1 一个焦点真的是一个盘算密集型最快吗?

是的。由于线程自己也是需要消耗资源的,频仍的切换实在对于盘算密集型线程没有任何利益,由于盘算量并没有变少反而变多了。

1.2 一个焦点真的是一个IO密集型线程最快吗?

纰谬。多个IO密集型线程一定比一个IO密集型线程要快,由于大部门时间,实在跟CPU没有关系,CPU大部门时间都是在等而已。以是让CPU一次性处置多个,反而加倍占有优势。

 

2、为什么不是并发量跟同时处置数相等时是最优解。

真实的营业场景,一条线程并不是纯粹的IO或者盘算,更多的时刻是处于两者都有的情形。那么对于这种线程的话。横竖不是一核一个最快,由于它毕竟是存在IO的情形。他们一定要多处置几个才划算。

这样服务器守候客户端请求的时间就太长了,若是并发数目跟处置数目相等的话,那么对于一个并发来说,就相当于客户端提议请求、发送网络数据、服务器处置、发送网络数据、客户端吸收网络数据,然后举行下一轮处置。这样的话就相当于客户端与服务器端处于同一个线程,单线程事情,而且中心存在了大量的守候的时间,以是服务器的QPS并不会上来。

 

最理想的状态应该是,以下的状态

  • 守候行列中始终存在数据(不会让处置线程守候客户端请求)
  • 客户端的请求进入守候行列后立马被处置(不会由于其余请求而造成响应时间过长,而引发下一步的守候行列过长)

凭据上边总结的多线程的相关结论,一样平常一个焦点一定要处置多个线程,而且守候行列中存在而且存在不了若干数据。

那么最佳并发的结论应该是,焦点数 * N(单焦点同时处置线程数) + M(守候行列中存在的少数请求)。

 

题外话:为什么Golang号称行使协成能够更好的行使CPU 到达更高的运算效率呢?

我猜应该是将IO型线程中的多线程切换部门性能节省下来,用作于更多的CPU盘算来提高了整体性能。

 

,

阳光在线

阳光在线www.xiangxiren12.com(原诚信在线)现已开放阳光在线手机版下载。阳光在线游戏公平、公开、公正,用实力赢取信誉。

Allbet声明:该文看法仅代表作者自己,与本平台无关。转载请注明:山西大同地图:C# 多线程料想

网友评论

  • (*)

最新评论

  • 欧博allbet网址 2020-06-30 03:00:17 回复

    联博以太坊www.326681.com采用以太坊区块链高度哈希值作为统计数据,联博以太坊统计数据开源、公平、无任何作弊可能性。联博统计免费提供API接口,支持多语言接入。现已加入我的最爱

    1
  • 环球UG官网 2020-10-05 00:03:54 回复

    联博统计www.326681.com采用以太坊区块链高度哈希值作为统计数据,联博以太坊统计数据开源、公平、无任何作弊可能性。联博统计免费提供API接口,支持多语言接入。总之加油吧

    2

文章归档

站点信息

  • 文章总数:709
  • 页面总数:0
  • 分类总数:8
  • 标签总数:1303
  • 评论总数:292
  • 浏览总数:21534