容量规划概述(2)

　　实施步骤

　　将线上一台节点offline，测试客户端直连被测服务器

　　客户端梯度增加并发(50),不断增加并发直至超过设定的服务指标

　　优缺点

　　测试效果不受服务实际流量的限制，压测时间灵活，适用于GET请求不会产生脏数据。业务指标可以通过测试客户端直接获取。

　　风险评估

　　风险低，首先机器offline不会影响到线上的正常请求;其次缓慢增加并发，不会造成服务崩溃的情况。

　　线上引流

　　线上引流，即将线上其它节点的请求复制到被测服务器上，推荐使用Tcpcopy工具。

　　测试数据：线上请求直接复制引流，无需准备数据

　　实施步骤

　　将线上一台节点Off-line，按照Tcpcopy部署的方法部署client和server，为了便于指标的统计，通常将Tcpcopy部署在nginx所在服务器，被压测服务器前需要增加一层nginx服务器。

　　将集群的其它节点流量复制到off-line节点上，可以通过tcpcopy –r参数逐步增加复制系数，不断增加-r参数直至超过设定的服务指标

　　如果100%全部线上流量都不能压测到off-line节点的瓶颈，再逐步放大引流系数

　　优缺点

　　请求真实，能够放大流量，测试效果不受服务实际流量的限制，压测时间灵活，但环境部

　　署稍微麻烦，对于PUT请求需要做一些业务处理，避免产生脏数据。

　　风险评估

　　风险低，首先机器offline不会影响到线上的正常请求，缓慢增加流量复制，不会造成服务崩溃的情况。

　　修改负载权重

　　对于一个集群，前面往往会有负载均衡服务器，以Nginx为例，通过修改Upstream模块的负载均衡weight可以不断增加集群某一节点的请求数，增加其访问压力。

　　测试数据：无需准备

　　实施步骤

　　缓慢增加nginx的负载均衡系数，使被测节点压力不断增加

　　直至超过设定的服务指标停止增加压力

　　优缺点

　　完全真实的场景，压测数据准确，但是依赖自身的流量，压测时间不灵活，需在高峰期，对用户体验有一定影响，随着一台机器的负载增加响应时间会受到一定影响，会直接反馈给在线用户。

　　风险评估

　　风险低，虽然在高峰期进行，但是只需要修改nginx配置再reload，对服务基本无影响，且每次都逐步增加weight，不会造成服务器崩溃的情况。

　　Step6 线上监控

　　线上监控不仅用于集群历史数据的收集，计算集群的实际负荷的监控，还用于压测过程中监控约束条件中的各种指标是否超限并停止压测。根据集群的特点和之前性能测试经验关注容量指标和约束条件的业务和资源指标。而这里的历史数据，是需要长期的采集和整理。

　　小结

　　综上所述，容量规划主要围绕着这么一个等式展开工作，纸上谈来终觉浅，实践出真知。希望能够在接下来的实践中成长和收获。

原文转自：http://www.uml.org.cn/Test/201406132.asp