或者我是如何学会停止担心和热爱新文物监测服务的你知道那种感觉。。。您刚刚将新服务投入生产。。。现场直播。。。你有用户点击这个东西。。。现在是问题出现的时候起来。什么你说的问题。。。其中一个原因是，我在服务上的新文物监测结果显示，随机得分不到0.7。。。然后它就会恢复。。。但是对于一个我对设计满意的应用程序（我不想声称设计是完美的，甚至是好的。。。但我没有抱怨）这不应该是箱子。还有更奇怪的是，在发布之前，我已经在应用程序上加强了负载测试，但从未见过这样的情况问题。以及然后我在newrelict中发现了一个非常有用的小按钮，因为你已经将newrelic代理附加到了应用程序中，云分析，你现在可以运行一个profiler了在生产实例上…不停止生产！我不能强调这有多方便。在负载测试[1]时，我们没有发现问题，因为附加一个传统的探查器很容易。而且我们有真正的用户在使用该服务，所以我们无法承受停止应用程序并附加探查器的停机时间。。。所以点击，点击。。。等待5分钟并分析结果。我发现了什么。。。好吧，代码的一条路径是创建并再次销毁一个AsyncHttpClient实例（它被设计成一个可共享的长寿命quazi singleton），并消耗掉77%的CPU时间进行销毁。2分钟后，我替换了新实例，什么叫大数据分析，引用了我共享的长寿命quazi singleton，所有其他代码路径都在使用它，然后重新部署。。。这个结果：版本在04:20左右（不是我的时区）部署了错误修复程序，请注意两个实例上的CPU都降到了5%以下，响应时间稳定在一个好的低水平上……感谢New Relic，云指，你帮我找到了一个只在生产负载下出现的bug。注：其中之一负载测试的问题在于，您必须定义您的场景，虽然您可以向每个场景添加一些随机性元素，但您无法提供真实用户所发生的真实随机性。在我们的例子中，我没有在有错误的代码路径[2]上设置足够的随机性，云 服务器，所以我的缓存层对这些值很敏感，并掩盖了这个问题。真正的用户对你的代码不是那么好！如何对新用户通过特定的第三方OAuth服务注册的代码路径进行负载测试？您需要在该服务上创建大量的假帐户并将它们输入负载测试程序。。。或者你作弊，像我做的那样，数据建模，用2-3，每隔10-15秒就把他们的记录从数据库里抹去。。。是的。。。只是乞求一个热缓存伪装错误！-斯蒂芬康诺利云蜂cloudbees.com网站Stephen Connolly有近20年的软件开发经验。他参与了许多开源项目，包括Jenkins。Stephen是Jenkins项目的首批非Sun成员之一，他开发了天气图标。斯蒂芬住在爱尔兰都柏林，那里的天气图标特别有用。在Twitter和他的博客上关注斯蒂芬。