注：我们忽略了CPU资源的需求，一般压测是I/O密集型，所耗费CPU资源不是很多，但也要小心，有时需要降低或关闭掉在压测端进行一些高频的数据校验行为。

　　理论和现实总是有差距存在，要做100万用户的压测，如上所述，我们没有大量空闲服务器，有的是若干16GB小内存、单一内网IP地址的线上服务器，需要因地制宜：

留有缓冲余地，每一台压测机平均分配5万个用户；

1台服务器用作压测主机；

20台线上服务器作为压测机。

　　提前计算和准备好压测使用的服务器，下面该进入设计业务压测会话内容环节了。

　　设计业务压测会话内容

　　紧密贴合业务设计压测，会话内容将是需要考虑的重心。

　　【压测连接信息】

　　怎么填写压测连接服务器地址、压测从机，根据Tsung手册操作即可。篇幅所限，不再赘述。

　　若是压测单台业务服务器，用户每秒生成速率需要避免设置过大。因为业务型服务，一般以处理具体自身业务为先，在用户每秒产生速率过快情况下，针对新建网络连接的处理速度就不会太快。

　　比如我们实践中设置每秒产生500个用户对线上若干台服务器压测，可避免因为产生过快影响到线上其他具体业务。

　　实践压测环节中，可能需要考虑很多的事情：

会不会突然之间对LVS网络通道产生影响，需要和网络组同事进行协调；

会不会因为突然之间的压力导致影响到其他现有服务；

一般建议，非封闭的网络环境下将用户每秒压力产生速度设置小一点，保险一些。

　　【设计压测会话内容】

　　压力测试会话内容的编写，有三个原则需要注意：模拟、全面和强度。

　　我们在设计压测会话时，一定要清楚所开发系统最终面向的用户是谁，其使用习惯和特征分别是什么，一定要尽可能的去复现其使用场景。其次，需要模拟的用户会话内容要全面覆盖用户交互的各个方面，比如聊天室项目中，一个用户从加入房间，中间流程包括点赞、打赏、光柱、发言等行为，中间间隔的心跳等，最后可选择的退出行为，其业务场景，完整的体现在编写的压测场景中了。另外，针对业务场景特点，还针对每一个具体的行为，还要考虑其执行次数等，简简单单走一遍流程，也就失去了性能压力测试的意义了。

　　下表是在压测聊天室这个业务时压测会话，包含了一个终端用户的完整交互。

　　安装和部署

　　Tsung安装部署要求简单：

所有压测服务器上安装有同样版本的Erlang和Tsung

服务器之间SSH通道需要设置成免密钥自动登录形式

　　这针对一般的机房环境是没有什么问题，但网络环境是很复杂的，问题总是会多过设想。

　　【SSH不可用时的替代方案】

　　但SSH通道会被系统管理员出于安全考虑禁用，导致Tsung主节点无法启动从节点，无法建立压测集群。我司机房网络环境就是如此，既然SSH不可使用，那么需要寻找/编写一个替代者。

　　一般情况下，Tsung主节点启动之后，从tsung.xml文件中读取从机列表，进而启动：

　　erlang slave:start(node_slave, bar, "-setcookie mycookie")

　　然后被翻译为类似于ssh HOSTNAME/IP Command命令：

　　bash ssh node_slave erl -detached -noinput -master foo@node_master -sname bar@node_slave -s slave slave_start foo@node_master slave_waiter_0 -setcookie mycookie

　　这很好解释了为什么压测节点之间需要提前设置SSH免密钥登录了。