如何评估服务器的单机处理能力
如果评估一台server的单机接入和处理能力？ 每秒钟能支持多少并发请求？ 当你的leader问你这个问题的时候，你知道怎么应对吗？
其实这个问题并不难，首先要评估一下这个server的业务模型是什么样的，瓶颈在那儿，一般来说可以分为cpu/内存/网卡，对于下载或流媒体业务来说网卡会成功瓶颈，但对于一般的逻辑server而言，瓶颈一般是cpu，对于一般的cache机机而言，瓶颈一般是内存。
分析出系统的瓶颈后，再针对瓶颈做的压力测度就可以了。对一般的逻辑server而言，完全可以可以开启若干个client并发请求，并对在不同的每秒并发量时top看系统的性能就可以了。但有时这样做还是不够的，因为模拟的并发量可能并不能准确地评估线上的真实场景，其实，完全可以“灰度放量”一部分用户后，观察系统的负载就可以大致估算出来了。下面给大家看一个例子：
这台server采用TCP长连接，单个入包在64字节-100字节之间，回包在1000字节左右，内存开销并不高，100个处理进程，每个进程使用4M内存用于处理收、发包的buf，所以内存也不是瓶颈，由于server主要处理业务逻辑，并与后端的存储层交互，所以瓶颈基本在于cpu。下面看一组数据，完全是上线后的真实数据。
1.1500/s
top - 17:11:25 up 17 days, 22:43, 1 user, load average: 5.81, 7.32, 8.60 Tasks: 189 total, 8 running, 179 sleeping, 0 stopped, 2 zombie Cpu(s): 30.4%us, 14.9%sy, 0.0%ni, 50.7%id, 0.0%wa, 0.0%hi, 4.0%si, 0.0%st Mem: 8305636k total, 2152036k used, 6153600k free, 425228k buffers Swap: 2104504k total, 0k used, 2104504k free, 1065372k cached
2.1800/s
top - 23:03:05 up 17 days, 4:35, 1 user, load average: 5.06, 5.28, 5.08 Tasks: 190 total, 6 running, 182 sleeping, 0 stopped, 2 zombie Cpu(s): 29.2%us, 20.1%sy, 0.0%ni, 46.3%id, 0.1%wa, 0.0%hi, 4.2%si, 0.0%st Mem: 8305636k total, 2194556k used, 6111080k free, 429908k buffers Swap: 2104504k total, 0k used, 2104504k free, 1100784k cached
因为这台server瓶颈不是内存，而是cpu的处理，所以这里看cpu 的idle基本可以评估出系统最大的支持能力。在系统1500/s时有50%的idle，在1800/s时有46%的idle，大概增加300/s cpu会耗大概5%，那基本可以估算出在2400/s时，cpu大概是36%的idle，但系统在负载较高时处理能力会略有下降，所以会低于36%，后来压测了一下，大概是31%idle，这样算下去，系统大概可以支持到3000/s，系统大概有15%的idle，这时系统应该就到满负荷了，所以2800/s应该是系统效率最高的情况。
这样，就大概评估出了这个系统的接入和处理能力，那么什么时候扩容也就了然于心了。不过有一点需要注意的是，系统在80%负载的时候利用率较高，也比较安全，负载再高的话，业务就有风险了。因为线上的情况多种多样，有时用户行为是不好评估的，这还不算自然增长。昨天我就碰到这样的情况，这就是上面这台server，昨天下午发完一个版本后，发现cpu只有31%的idle，统计了下请求量，2400/s，而前天同一时候，才1200/s-1400/s，为什么会有这么大的增幅呢，肯定是不正常的，看了一下出入包量，也有成倍的增长，难道是用户的行为发了一变化，回想了刚才版本的修改，才想到由于刚才的版本特性，引导用户有问题，导致用户重复操作，产生的滚雪球的效应，不过还好，用户试了几次后发现不行就放弃了，否则server肯定会挂掉的。如果不是之前负载比较低的话，恐怕当时就挂了。有时为了负载均衡和容灾的考虑，也要保证server的冗余。
其实cpu只是一个标准，评估系统的能力是件需要深入探讨的理题，后面会继续学习并和大家分享！