关于高并发的一些笔记

 

四核八线程云主机，
如果10w要求一秒内响应，
后台处理200ms,

且API属于CPU密集型，
那么考虑最坏情况，

假如这其中有1w个请求发生在同一时刻点。
要在一秒内响应的话。。。需要的数量是?

 

其实稍微思考下就可以知道，如果每200ms都只能完成1w个请求的处理，那么1s结束后就只能完成5w的请求．

所以上面的问题是有毛病的，答案是至少是2500台．

 

另外IO涉及很多方面：

mysql的IO，硬盘的IO以及网络的IO，以及锁的情况也会影响响应速度，比如行锁和表锁．

 

另外高并发的定义中，总是说"一定时间间隔内",[1]是一个很有意思的参考链接，他清晰地说明了高并发其实只是一个含糊的概念，要高并发其实要讲清楚客观条件，才有比较的意义．

 

来自“天使的眼睛”

单机可以做高并发测试，一般来说主要限制是在网络上(要么是网络速度，要么是网卡速度)

通常：

第一限制是网速(例如只有10G的对外出口频宽)

第二限制是网卡(硬件)加入你只有20G或者40G的网卡。

第三限制是终端(Interrupt per second,其实这还是属于硬件问题)

CPU跟内存的限制并不大

 

 

 

 

天使de眼睛 2019/10/3 1:28:11
python比较讨厌的是fork的时候不能直接做affinity。

也没法选择CPU的scheduler。

如果你需要做“理论”高性能。

那么你直接threading部分用c来做（pthread就可以，booster也行）

然后python直接调用c模块的threading，这样既可以有affinity跟scheduler的支持，还不需要考虑gil的问题。甚至你可以直接给real time priority跟cgroup去做进一步的优化
天使de眼睛 2019/10/3 1:30:11
我们公司来说，并不去追求这种极限东西。因为是商业公司，赚钱为主。这种追求所付出的，远远超过了直接增加硬件所需要的成本（优化高并发，不如直接多上点机器就好了）
天使de眼睛 2019/10/3 1:32:40
纽约股票交易行业中。这种追求极限的比较多（特殊的定制网卡硬件，内核tcp stack的by pass，ip stack的重新架构，硬件的直接direct by pass等等）这些行业，一般技术行业有所谓的“unlimited budget”。只要钱能买到的，就做到极限

 

 

Reference:

[1]https://www.cnblogs.com/xiexj/p/10399385.html