Tag: playframework 2.0 netty

非常慢的播放框架2.3请求处理代码

我面临的方法表现极慢： HttpRequestDecoder.unfoldAndFireMessageReceived() 和 Future$PromiseCompletingRunnable.run() 这两种方法使用服务器中每个事务的大约一半时间。 它发生在低营养和高使用时间。 例如，凌晨1点，只有我对应用程序的请求，我得到了新的遗物图形，如下所示： 在这个事务中，只有这两个方法消耗1秒，甚至更慢，通过hibernate访问数据库！ 再一次，应用程序中只有一个用户。 如果交易较重，则需要更多时间： 在这种情况下，当我自己的代码消耗1.5秒，总共4秒时，这两种方法平均消耗2.5秒。 我觉得那个时刻可能只是误导了新的遗物标准。 也许newrelic会显示这些方法名称，但它确实是我编写的代码。 所以我决定得到一个像这样的自定义指标： playController(){ //Start timer //do the job //stop the timer() and send metric to new relic //return; } 结果是我的代码耗时1.5秒。 所以这次是真正的游戏请求处理程序。 这种行为在高负荷时会杀死我的应用。 当throghput每分钟大约500个请求（实际上不是高吞吐量！）时，这两种方法可能消耗长达20秒，但我的代码保持稳定在最多3秒。 我真的不认为这是一个线程问题，因为它甚至在有一个用户的时候就会发生，但是当有很多并发请求时它会变得很麻烦。 我尝试改变“同步应用程序”的线程数量，例如文档提及，但我没有得到任何性能改变，它甚至变得更糟。 我真的很担心这个问题，因为在两年多的游戏邮件列表中有类似的情况而没有答案！： http://grokbase.com/t/gg/play-framework/159bzf7r9p/help-to-understand-newrelic-report-for-slow-transactions-2-1-4 在StackOverflow中甚至有一个类似的问题，但对于没有回答且没有明显活动的游戏2.1： 使用Play Framework作为后端的NewRelic中的交易缓慢 什么可能导致这种行为的想法？