【发布时间】：2016-03-27 12:40:16
【问题描述】：
我正面临方法性能极慢的问题：
HttpRequestDecoder.unfoldAndFireMessageReceived()
和
Future$PromiseCompletingRunnable.run()
这两种方法使用服务器中每个事务大约一半的时间。它发生在低吞吐量和高使用时间。
例如，在凌晨 1 点，只有我向应用程序发出请求，我在新的遗物中得到了如下图：
在这个事务中，只有这两个方法消耗了整整一秒，甚至比通过休眠访问数据库更慢！再一次，应用程序中只有一个用户。
如果事务较重，则需要更多时间：
在这种情况下，这两种方法平均消耗 2.5 秒，而我自己的代码消耗 1.5 秒，总共需要 4 秒。我当时认为这可能只是对新遗物指标的误导。也许 newrelic 显示了这些方法的名称，但它实际上是我编写的代码。所以我决定得到一个像这样的自定义指标：
playController(){
//Start timer
//do the job
//stop the timer() and send metric to new relic
//return;
}
结果是我的代码需要 1.5 秒。所以真正消耗这个时间的是播放请求处理程序。
当负载高时，这种行为正在杀死我的应用程序。当吞吐量约为每分钟 500 个请求时，这两种方法最多可以消耗 20 秒（不是真正的高吞吐量！），但我的代码保持稳定在最多 3 秒。
我真的不认为这是一个线程问题，因为它甚至在只有一个用户时发生，但是当有很多并发请求时它变得非常有问题。我尝试更改文档中提到的“同步应用程序”的线程数，但我没有得到任何性能变化，甚至变得更糟。
我真的很关心这个问题，因为在play的邮件列表中有一个类似的案例，两年多没有答案！：
在 StackOverflow 中甚至还有一个类似的问题，但对于 play 2.1 没有答案且没有明显的活动：
Slow transactions in NewRelic having Play Framework as backend
有什么想法会导致这种行为吗？
【问题讨论】：
-
您使用的是哪个版本的newrelic代理？此外，代理本身可能会增加一些开销：discuss.newrelic.com/t/java-agent-overhead/26870
-
另外，既然您说您使用的是 Hibernate，我只能假设您正在对数据库进行块/同步访问。您应该尝试为您的线程池尝试不同的配置。
-
嗨@marcospereira。我正在使用新的遗物 3.25.0。我不认为 newrelic 是问题，因为我正在试验非常缓慢的响应，所以我决定实施 newrelic。换句话说，在性能问题出现后才实施新的遗物。关于 Hibernate，我几乎可以肯定这不是数据库/ORM 问题，因为我正在使用自定义指标（没有 newrelic 提供的默认值）测量时间，并且 services-daos-queries 的执行速度非常快。
-
@marcospereira 感谢马科斯的帮助。问题是新的，不是开销，而是错误的度量记录。就像您提到的问题是数据库访问，但是由于 newrelic 报告说 10% 的事务时间是数据库访问，这误导了团队很多时间！我们使用许多分析器、慢查询日志和 AppDynamics 发现了这个问题。
标签： java performance playframework playframework-2.0 netty