我们正在创建一个简单的网站,但有用户登录(大约25000个并发用户)。我该如何计算不。需要支持它的实例?
答案 0 :(得分:8)
负载测试和性能测试确实是您了解应用的性能指标和实例要求的唯一方法。您需要定义“并发用户” - 这是否意味着25,000个并发事务,或者这仅仅意味着25,000个活动会话?如果是后者,用户访问网页的频率(例如,页面之间的思考时间)?然后,还有所有其他活动部分:数据库,Azure存储,外部Web服务,角色内部通信等。处理管道中的所有这些步骤都可能成为瓶颈。
不要忘记SLA:假设您可以支持25,000个并发会话(不是每秒的事务数),那么可以接受的往返时间是多少?两秒钟?五?
在考虑实例计数时,还需要考虑等式中的VM大小。例如,根据您的处理管道,您可能需要中型或大型VM来支持特定的内存要求。在测试不同的VM大小时,您可能会得到完全不同的结果。
您需要有一种方法来执行可重复的经验测试并消除边缘情况错误(例如:运行测试至少3次以获得平均值;并以明确定义的方式有条理地增加负载并且在该负载下观察结果一段时间,以允许增加负载的混乱行为以稳定)。这种经验测试包括精心设计的测试计划(例如,用户将针对给定的使用场景命中哪些页面,包括可能的表单数据)。并且您将需要适当的工具来监控被测系统,以确定给定负载何时产生“曲线中的拐点”(意味着您遇到瓶颈并且性能急剧下降)。
最后的想法:确保您的负载生成工具不是测试期间的瓶颈!您可能希望使用Microsoft的负载测试解决方案与Visual Studio,或基于云的负载测试解决方案,如Loadstorm(免责声明:Loadstorm interviewed me去年关于负载/性能测试,但我不以任何身份为他们工作。)
编辑2013年6月21日在TechEd 2013上宣布,Team Foundation Service将提供基于云的负载测试,预览将于6月26日发布,与// build会议同时进行。公告为here。
答案 1 :(得分:2)
没有更多信息,没有人可以回答这个问题......比如你用什么技术来构建网站,页面加载会发生什么,使用什么后端存储(如果有的话)等等。对于每个登录的用户来说,你计算了一百万个pi的数字,或者对于你从缓存中提供静态内容的每个用户来说都是如此。
我最好的建议是测试你的应用程序(在云端或同等硬件中),看看它是如何运行的。
答案 2 :(得分:1)
这完全取决于您每秒执行的架构设计,持久性技术和读/写操作数(平均值/峰值)。
我建议您查看CQRS-based architectures这种应用程序。它适合云计算环境,并允许弹性扩展。
答案 3 :(得分:0)
我最近参加了云峰会,并进行了一些案例研究。我想到的是考试应用程序。它在2小时内有大约80000个用户的突发负载,为此他们启动了大约300个实例。
在不知道您的负载配置文件的情况下,很难添加更多价值,请记住并发和连续不是一回事。还记得Stack溢出与Digg崩溃“http://twitter.com/#!/spolsky/status/27244766467”吗?