世界杯结束了！放“大招”：扒一扒ECS虚机的并发性能

闲来无事，玩一下阿里云的服务器。一直都想实际测一下Aliyun服务器的并发性能，但苦于没有合适的工具，只好自己动手了。关于测试工具的源代码和使用方法，会另开帖子介绍一下。

实验的基本思想就是模拟8~128个并发请求到一台网页服务器，每个并发持续请求一段时间，绘制该网站CPU、内存、带宽的性能曲线；计算出每次请求的平均响应时间MRT，根据并发请求数SCR计算出网页服务器在各并发请求下的QPS。
基本概念：

SCR : 并发请求数

MRT: 每次请求的平均响应时间（秒）

QPS和MRT、SCR的关系：

QPS = SCR / MRT

实验模型：

为了避免单台ECS实例的线程性能瓶颈，这里使用了多达8台的ECS服务器作为施压服务器，每台服务器最大并发16个请求。

为了避免网络带宽成为服务能力的瓶颈，这里将8台施压机和被测服务器放在同一个Region和安全组内，内网带宽假设为1G。

为了更好的看出实验性能，施压和被测服务器均选用同类型的4核4G服务器。

[attachment=56349]

测试过程

被测服务器4核4G：

centos + apache + php + fpm， apache和php禁用缓存，放开Max请求数，apache没有设置压缩页面。

开机自动运行Python脚本每秒收集被测服务器的性能数据， CPU、内存、带宽的使用比例。

被测页面是简单的phpinfo 页面，静态页面大小约50K左右。

施压服务器，8台4核4G和被测实例同类型：

接收控制端指令，创建线程模拟URL请求，下当页面下载完成并HTTP Code为200时视为一次请求成功，其余状态为失败。

施压机的压力测试工具开机自动运行，记录每次请求的响应时间、成功/失败次数。测试工具是基于curl自主开发的，创建线程并发请求phpinfo页面。施压机已被做成镜像，用CLI工具可以更快的创建和管理自己的施压机。（实在不喜欢在控制台上管理实例）

CLI工具下载： http://bbs.aliyun.com/read/163193.html

控制器，楼主的笔记本电脑：

向每台施压机发出测试指令，每台施压机模拟1~16个并发请求，每个等级的并发连续请求30S。

总的并发阶梯就是： 8 16 24 32 40 48 56 64 72 80 88 96 104 112 120 128

测试结果

服务器性能指标和QPS性能曲线

[attachment=56346][attachment=56347]

通过以上实验过程可以看出，

带宽曲线和CPU曲线惊人的一致，同上同下。
动态网页考验的是CPU性能，与带宽相比，当并发逐渐加大时CPU会最先达到100%。
在并发超过56后，网站的性能开始不稳定，并发数56应该是4核4G实例的并发瓶颈。
当被测实例性能达到高峰时，带宽使用了500M左右。但实际上当网络达到500M时，ECS的价格已经是天价。