为了保证调优努力的成功你能做的最重要的事就是安排时间了解你的用户和理解他们在使用你的应用时的行为情况。很少会在生产环境中调优应用服务器，而更多的情况是,通过写测试脚本再现为虚拟用户，在上线前的环境中执行负载并进行调优。当在上线前环境中完成调优后, 就可以安全地把配置信息应用到生产环境中。多数公司无法在上线前的环境中充分地再现生产负载。如果您在这些公司中工作,没必要失望。多数大型的公司并没有对他们的用户行为有很好的理解并且在测试环境中不能产生有代表性的负载。
有两个共同的似是而非的理由：
1. 生产负载太大，在上线前无法模拟。
2. 我没有任何办法知道我的最终用户到底是如何操作的。
针对第一点,我们可以在上线前环境中建立一个按比例缩减的生产版本，当在生产环境中部署时，再按比例放大。虽然没有做一个生产环境的镜像有效，但是有时并值得那么做。针对第二点，下面将说明如何采集最终用户的操作行为。
由于我们需要在投入生产之前设法在上线前的环境中调优我们的应用系统，这样才能验证配置，所以一个随之而来的问题就是我们需要在这个环境中执行的负载测试脚本。对一个企业应用进行调优的步骤包括实施一些最佳实践设置，负载测试应用，观察应用的行为，以及适当调整配置参数等。这是一个叠代过程，我们需要不断调整以达到最优的配置。一些调整可能会提高性能，而一些会降低性能。这也是为什么性能调优不应该放在开发周期后期的一个原因。
假设我们根据我们的负载脚本进行调优，那对你又意味着什么呢?这意味着负载脚本应该真实反映现实世界用户的使用行为。假设我们在优化一个Web搜索引擎，我们可以写一个测试脚本，该脚本总是在测试苹果和香蕉，但是用户是这样使用吗?我们可以为此调整出最好的性能。但是当查询Bea和IBM时，又会怎样呢?在我的应用中，我可以将技术公司的词汇放在与水果和蔬菜不同的数据库中，那么在测试环境中，永远不会执行到那段代码，我们的调优努力也就徒劳无益了。
更好的解决办法是确定名列前茅1000 或10,000 个查寻词组和他们频率。然后,计算每个被请求的时间百分比并且编写按照该百分比查询这些词汇的测试脚本。对于剩余的百分比，你可以把负载测试工具连到一个词典，可以随机生成查询的词汇。
文章来源于领测软件测试网 https://www.ltesting.net/
