应用程序的性能应该符合其预期使用要求。如果任何时候都不会有超过100个用户使用新服务，那么就没有必要设置每秒300个并发连接的性能目标。这些武断的性能指标是浪费时间，而且可能会让新网站发布过程中的的质量保证阶段产生严重拖延。
 
虽然技术人员和技术主管们都希望提高应用程序的性能，但团队不能因为过分关注性能而影响最终用户的响应时间。测量最终用户真实响应时间的唯一方法就是在全国或全球各地建立服务器，然后定期访问一个网页，如每隔15~30分钟。这就是所谓的真实浏览器性能测试，也是种监控Web应用程序运行状况的长期方法。它可以最有效地确定一个Web应用程序的运行性能。通常，这些过程由第三方公司执行，他们会代表客户在指定的位置执行测试。 Keynote和 Gomez就是两家能够提供这种服务的著名公司。对于大多数公司而言，建设这种基础架构的成本可能太高了，而且需要投入大量的资源，但是回报甚微。因此，最好是使用一些专业公司提供的服务，他们的核心竞争力就是提供Web性能监控和测试服务。


 
生产环境测试并不一定意味着要将新产品发布到生产环境中执行，因为如果出现问题，则可能会破坏品牌形象。如果给现有网站引入一个新特性，或者修改其中一个重要部件，那么最好先导入一小部分流量将网站的新特性或修改部分交付这部分用户使用。应用程序在内部通过了全面测试之后，最好要分析用户流量对新应用程序、网站或特性的影响。这种方法一定要谨慎使用，因为这个特性只让少数用户测试过，这并不代表全负载运行不会出现问题。这种方法的效用主要在于，它可以为我们提供以下数据
 
只有在生产负载下才会发生的错误和行为；
知名度数据有多少用户愿意和喜欢使用这个新特性；
性能标准。
 
这种方法可以用流量汇集技术实现，即让负载均衡程序根据URL导入一部分流量。例如，包含新代码的Web服务器或应用服务器可能有个URL: /beta/player。该可能位于一个服务器群的10101000阿络中。大多数负载均衡程序都可以配置为只允许一定比例的流量或会话进入包含新应用程序或模块的应用程序或Web服务器。
 
在受控的生产环境测试设置中收集到一些性能和日志数据之后，我们就可以分析这些数据，将它们与内部测试和合成测试的结果进行比较。
 
如果测试对象不是现有网站制作的一个新特性，而是一个全新发布的网站，那么测试就更加重要了。许多新建或全新的网站都需要加入一个邀请页面，然后邀请一部分用户试用它们的服务。问题在于，这些用户是经过选择的，他们知道自己是Bea测试用户，他们的作用是帮助开发者修改错误，协助最终正式发布。执行密集内容测试和少量生产环境测试，然后将生产使用及错误数据与内部测试数据进行比较，这个过程完全相同；它们的区别在于新网站的访问限制是通过一个选择加入列表来控制的，而不是使用自动化的负载均衡和根据一些条件(如年龄)来识别用户的标记系统。