使用这些指标(如下所示(，我能够利用工作负载建模公式(利特尔定律(来提出我认为正确的设置，以便对有问题的应用程序进行充分的负载测试。
来自Google Analytics：
- 用户：2159
- 页面浏览量：4856
- 平均。会话持续时间：0:02:44
- 页数/课时：2.21
- 会议：2199
公式为N=吞吐量*(响应时间+思考时间(
- 我们计算吞吐量为1.35(4865次页面浏览/3600(一小时内的秒数((
- 我们计算出(响应时间+思考时间(为74.21(平均会话持续时间164秒/每次会话2.21页(
使用该公式，我们将N计算为100(1.35吞吐量*74.21(响应时间+思考时间((。
因此，根据我的计算，我们可以模拟服务器在高峰时段的高峰日所经历的负载，100个用户在迭代之间以75秒的速度完成业务流程(忽略时间(。
因此，为了确定系统在比正常负载更重的情况下如何响应，我们可以将N的值增加一倍(200个用户(或三倍(300个用户(，并记录每个事务的平均响应时间。
这都对吗？
当您直接观察站点的日志时，按会话持续时间进行阻止，每个阻止中的最大IP地址数是多少？
Littles定律倾向于低估会话及其开销，以利于事务吞吐量。如果您对会话资源进行了即时恢复，但大多数站点保留会话资源的时间都超过了用户最长请求间窗口(从一个请求到下一个请求的时间(的110%，这也没关系。
下面的公式对我来说一直很有效，如果你想计算节奏"Pacing = No. of Users * Duration of Test (in seconds) / Transactions you want to achieve in said Test Duration"
你应该能够使用这个公式更接近你想要实现的交易。如果它是API，那么它几乎总是准确的。
例如，您希望在一小时的测试持续时间内使用5个用户实现1000个事务
起搏=5*3600/1000=18秒