以Play框架为后端的NewRelic中的交易缓慢 [英] Slow transactions in NewRelic having Play Framework as backend

查看:70
本文介绍了以Play框架为后端的NewRelic中的交易缓慢的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

有人可以帮助我阅读NewRelic摘要和跟踪详细信息.以下屏幕快照跟踪单个事务,该事务不会对数据库创建任何查询.这只是一个简单的查询,只有几行Scala模板代码,该代码呈现HTML页面并将其返回给客户端.这只是当前正在生产中运行的单个事务.生产中运行着许多更复杂的事务,这些事务对Mongo,Maria,Queue等进行了许多外部调用.

该痕迹是否揭示出瓶颈可能在哪里?例如,我们是否用完了线程或工作者.正如我所说的,大多数事务都会进行大量的Web外部调用,这可能会在很长一段时间内保留单个Thread.如何实际研究线程或工作者在Play应用程序中是否用完了?我们正在使用2.1.4.

接下来的通话实际上会发生什么?

Promise.apply 21.406ms

异步等待21.406ms

Actor.tell 48.366ms

PlayDefaultUpstreamHandler 6.292ms

拨打电话的目的是什么?这些人的平均通话时间超高.

scala.concurrent.impl.CallbackRunnable.run()
scala.concurrent.impl.Future$PromiseCompletingRunnable.run()
org.jboss.netty.handler.codec.http.HttpRequestDecoder.unfoldAndFireMessageReceived()

play {
  akka {
    event-handlers = ["akka.event.slf4j.Slf4jEventHandler"]
    loglevel = WARNING
    actor {
      default-dispatcher = {
        fork-join-executor {
          parallelism-min = 350
          parallelism-max = 350
        }
      }
      exports = {
        fork-join-executor {
          parallelism-min = 10
          parallelism-max = 10
        }
      }
    }
  }
}

解决方案

我不确定一年后对您是否有帮助,但是我认为您遇到的性能问题与Play,Akka或Netty无关. /p>

问题将出在您的代码业务逻辑或数据库访问中.您看到的PromiseCompletingRunnable和unfoldAndFireMessageReceived的重要时刻具有误导性. newrelic以错误和误导性的方式报告了此时间.请阅读这篇文章:

极端慢播放框架2.3请求处理代码

我遇到了类似的问题,我的数据库中有数据库,但newrelic的网络净值却很高.

我希望这对您有帮助.

could someone help me to read NewRelic Summary and Trace details. Following screenshots have trace for a single transaction, which do not create any query to the database. It is just a simple query with few lines of Scala template code, which renders HTML page and returns it to the client. This is just a single transaction that is currently running in production. Production has plenty of more complex transaction running which do lots of external calls to Mongo, Maria, Queue, etc.

Does the trace reveal anything about where bottleneck could be? Are we for example running out of Threads or Workers. As I told most of the transactions do lots of web external calls, which might reserve single Thread for quite long time. How one can actually study if Threads or Workers are running out in Play application? We are using 2.1.4.

What actually happens in following calls?

Promise.apply 21.406ms

Async Wait 21.406ms

Actor.tell 48.366ms

PlayDefaultUpstreamHandler 6.292ms

Edit:

What is the purpose of following calls? Those have super high average call times.

scala.concurrent.impl.CallbackRunnable.run()
scala.concurrent.impl.Future$PromiseCompletingRunnable.run()
org.jboss.netty.handler.codec.http.HttpRequestDecoder.unfoldAndFireMessageReceived()

Edit:

play {
  akka {
    event-handlers = ["akka.event.slf4j.Slf4jEventHandler"]
    loglevel = WARNING
    actor {
      default-dispatcher = {
        fork-join-executor {
          parallelism-min = 350
          parallelism-max = 350
        }
      }
      exports = {
        fork-join-executor {
          parallelism-min = 10
          parallelism-max = 10
        }
      }
    }
  }
}

解决方案

I'm not sure if this will help you 1 year later but I think the performance problems you were hitting are not related to Play, Akka or Netty.

The problem will be in your code business logic or in the database access. The big times that you see for PromiseCompletingRunnable and unfoldAndFireMessageReceived are misleading. This times are reported by newrelic in a wrong and misleading way. Please read this post:

Extremely slow play framework 2.3 request handling code

I faced a similar problem, and mine was in the database but newrelic reported big times in netty.

I hope this helps you even now.

这篇关于以Play框架为后端的NewRelic中的交易缓慢的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆