搞服务器性能时有感

这段时间一直在搞性能，由于要应对高并发的状况，每秒有2000用户的并发。

在这个并发里面，到底有多少请求的，其实要按照用户请求的页面来平均一下，若是说平均每一个页面要请求3个接口，那么2000用户并发的话，请求数就是：2000 * 3 = 6000；

服务器要在一秒内解决这6000个并发，换而言之，就是TPS为6000，这时候必须先假设前提条件：

带宽瓶颈

一、假设服务器是8核的，计算能力稳定，没有数据库请求的延迟状况。那么瓶颈在于带宽。若是你请求的接口返回的报文（response）是1k，那么

      服务器的带宽要多大？

      带宽 = 1k * 6000 = 6M

      这个带宽理论上就是你公网流出的带宽大小。可是，我在阿里的ECS里买的带宽是10M。据其文档所说

      很天然地认为，6000个TPS一点问题都没有，固然这是一种很理想的状态下。然而现实很骨感，你公网流出的带宽可能都是显示10M

   

    可是，在真正的测试用，也是用的阿里的性能测试TPS，峰值带宽得出的结果是

     

    这是怎么回事？看阿里的文档

   

       那实际的上下载速度多大呢，嗯……它实际就是符合 128KB x 带宽 = 实际上下载速度。因此，10M的带宽，实际流出（即服务器自己的上传速度）是 128KB/s X 10 = 1.2M。这样就合情合理了。因此，你TPS为6000，理论上来说须要多大的带宽呢？

      实际ECS须要的带宽是：6000 * 1KB / 128KB = 46.875M。

      这是在CPU无瓶颈状况下，支持6000TPS的带宽须要 46.875M。

 

CPU瓶颈

二、假设带宽无瓶颈的状况下，8核CPU每秒能处理的TPS的量是多大呢？实际上是不少因素有影响的，不能单独的只考虑CPU。那么以个人实际ECS来算好了，不一样机器不一样状况，只作参考！