《如何测试WEB服务器的最大并发数》由会员分享，可在线阅读，更多相关《如何测试WEB服务器的最大并发数（3页珍藏版）》请在金锄头文库上搜索。
1、1 满足最大并发数条件1) 用户都要成功2) 用户事务时间（以网页为单位，或整个脚本）需要在合理范围，一般是满足“2-5-8”原则，太长时间则认为用户也是失败的，因为一个网站如果响应时间太长，用户不能忍受，则会损失用户。2 如何测试最大并发数视频下载网址：http:/ ）该视频介绍了测试工具测试的最大并发数，并不能代表服务器支持的最大并发数， 因为很多测试工具（包括 loadrunner）运行的虚拟用户对服务器的压力要小于真实的用户，所以测试工具测试的最大并发数比实际要大，但大多少，是很难估算的， 有些 HTTP 吞吐量大，有些 HTTP 需要访问数据库或访问另一个服务器，即没个 HTTP的时
2、间有大有小，不能简单的平均，所以估算实际用户数很难，周边的人都这样认为，不知道有没高手有计算方法。所以只有模拟真实用户行为，才能简单得出系统最大并发数，让性能测试更轻松2 ）还有，该视频介绍事务的时间是有条件的。不是一般测试工具的事务时间，因为对于网站性能测试，一般测试工具不能模拟浏览器的行为，事务时间就无法用“2-5-8”原则来评估，而模拟了真实用户行为才能简单实用“2-5-8”原则来评估3 很多人认为并发数要么通过计算的出来 ，但怎么计算，是很难计算的假设一个页面有 A、B、C、D 四个请求，浏览器是并发他们的，但是 C 响应时间要 1 秒（访问数据库或后台服务器），其他 ABD 则很快
3、100 毫秒，则整个页面时间应该是 1 秒 所以测试工具能够模拟浏览器并发（每一个虚拟用户跟浏览器一样的并发数）并为页面设置了事务后，该事务值就表示了该页面的时间，用户都不需要计算。假设测试工具时串行的，则事务时间为 A+B+C+D，那么怎么得到页面的时间呢，很难计算的。肯定不是取平均值，因为一平均整个页面才 400 毫秒，跟实际情况不一样，实践情况还有 TCP 建立时间。 另外，在并发情况下 A 在每个用户的时间很大可能都不一样，B 也是，由于工具没有每个 HTTP 请求的时间，而是整个事务的时间，所以事务时间太大时，就不知道是哪个导致的， 因为可能在并发小时是 C 时间长，但并发大时可能是
4、 B（假设下载一个大图片）的时间长，或者 TCP 建立时间长，所以很难计算该事务换算成页面的时间；身边做性能测试有经验的人也是这样认为， 因为无法得到每个虚拟用户每个 HTTP 请求的信息，就算得到也很难计算。假设测试工具模拟里浏览器一样的行为（即是并行而不是串行）的，则 ABD是 100 毫秒，C 响应时间 1 秒时，整个事务的时间是 1 秒，与正常情况一样；如果是A 因为 TCP 重传变为 3 秒，而 C 才 1 秒，则整个时间是 3 秒，取最大那个，因为是并行的。 这样，测试工具测试的事务时间是多少，就表示用户访问该事务时多少时间，一目了然，不需要用户去计算。所以说通过测试工具(串行)的
5、输出的事务值再自己来计算，是非常难的，也很不现实，因为你不知道事务里面是哪个 HTTP 请求导致时间长但如果是测试工具能够模拟浏览器并发则事务输出的值是多少就表示页面多长时间，都不需要计算，一目了然，现在了解只有 kylinPET 工具做到这点，而loadrunner 与 jmeter 没有模拟浏览器并发行为。4 很多人认为服务器监控得到，但服务器监控到的并不代表最大并发数1）很多 WEB 系统是没有这个功能的，因为很多 WEB 服务器都没有用户信息2）假设有用户信息（用户名、状态），但用户登录后没退出，但浏览器已经关闭，即脚本已经运行完，然后 WEB 系统还存在该信息，只是超时才删除，这时候
6、统计的用户数不是最大并发数，而是在线数，因为用户这时已经没有对 WEB 系统有压力啦3）假设用户一直在线压，没有出现在线但没请求的去哪个看，那么有多少用户数，只是表示你的系统里面有这么多用户数据，也确实有这么多用户在处理，但由于测试工具没有模拟浏览器行为，这时测试用户数与真实的用户数是不一样的。因为真实用户数压力更大，这个可以看视频的例子所以，如果测试工具确实模拟了浏览器一样的压力，那么不需要查询服务器（很多测试人员可能不会，或者没条件），测试工具显示最大多少就是多少，用户一目了然，多好啊。这就是我一直强调模拟浏览器行为，然后根据事务时间符合“2-5-8”原则来进行性能测试，这样的思路才让性能测试更清晰，更轻松
