如何分析Akka应用程序？ [英] How to profile Akka applications?

问题描述

我有一个小型的Akka应用程序，该应用程序在其参与者之间传递许多消息，并且每个参与者对接收到的数据进行一些计算。我想要的是分析此应用程序，以便查看代码的哪些部分占用最多的时间，依此类推。

I have a small Akka application that passes many messages between its actors and each actor does some calculations on the data it receives. What I want is to profile this application in order to see which parts of the code take up most time and so on.

我尝试了VisualVM，但我无法真正理解正在发生的事情上。我添加了探查器输出的图片。

I tried VisualVM but I cannot really understand what's going on. I added a picture of the profiler output.

我的问题是

• 什么例如，这是第一行，为什么要占用这么多时间？ （scala.concurrent.forkjoin.ForkJoinPool.scan（））


• 由于Akka应用程序的异步行为，能否对其进行全面的分析？


• 例如，我可以看到一个特定角色（-类型）对其收到的特定消息（-类型）工作多长时间吗？


• 还有其他最佳做法吗概要分析Akka应用程序？

• What for example is this first line and why does it take up so much time? (scala.concurrent.forkjoin.ForkJoinPool.scan())
• Can Akka applications because of their asynchronous behaviour be profiled well at all?
• Can I see for instance how long one specific actor(-type) works for one specific message(-type) it receives?
• Are there other best-practices for profiling Akka applications?

推荐答案

• 有些软件包默认情况下未进行概要分析，这是他们的时间记入 scala.concurrent.forkjoin.ForkJoinPool.scan（）的配置文件中。如果允许对所有隐藏的程序包进行采样，则将显示真实的CPU时间消耗者。例如，以下之前/之后的说明性概要文件揭示了 sun.misc.Unsafe.park 大部分时间使线程处于休眠状态，等待释放。
  



• Akka应用程序可以通过适当的检测和调用跟踪很好地进行概要分析。 Google着名的 Dapper，大型分布式系统跟踪基础架构论文，其中详细介绍了技术。 Twitter在此基础上创建了 Zipkin 。它是开源的，并且具有用于Akka分布式跟踪的扩展。遵循其 Wiki 可以很好地说明如何设置允许

  • There are packages not profiled by default and it is their time that is accounted in the profile of scala.concurrent.forkjoin.ForkJoinPool.scan(). If all the hidden packages are allowed to be sampled, the true CPU time consumers will be revealed. For example, the following before/after illustrative profiles uncover that threads are put to sleep most of the time by sun.misc.Unsafe.park waiting to be unparked.

  • Akka applications can be profiled quite well with proper instrumentation and call tracing. Google's prominent Dapper, a Large-Scale Distributed Systems Tracing Infrastructure paper contains detailed explanation of the technique. Twitter created Zipkin based on that. It is open sourced and has an extension for distributed tracing of Akka. Follow its wiki for a good explanation of how to set up a system that allows to

    
    

    
    
    • actor系统内部的跟踪调用层次；
    
    
    • 调试请求处理管道（您可以登录到跟踪，并使用自定义键值对对其进行注释）；
    
    
    • 查看派生请求及其对最终响应时间的贡献之间的依赖性；
    
    
    • 查找并分析系统中最慢的请求。
    
    

    • trace call hierarchies inside an actor system;
    • debug request processing pipelines (you can log to traces, annotate them with custom key-value pairs);
    • see dependencies between derived requests and their contribution to resulting response time;
    • find and analyse slowest requests in your system.

    块， Kamon 。它是一种反应友好型工具包，用于监视运行在JVM之上的应用程序，这特别适合使用Typesafe Reactive Platform构建的应用程序。对于Akka来说，这绝对是肯定的，并且集成以 kamon-akka 和 kamon-akka-remote 的形式出现带有字节码检测功能的模块代表您收集度量并执行自动跟踪上下文传播。从 Akka集成概述开始浏览文档，以了解它可以做什么以及如何实现。 / p>

  
  

  There is also a new kid on the block, Kamon. It is a reactive-friendly toolkit for monitoring applications that run on top of the JVM, which is specially enthusiastic to applications built with the Typesafe Reactive Platform. That definitely means yes for Akka and the integration comes in the form of the kamon-akka and kamon-akka-remote modules that bring bytecode instrumentation to gather metrics and perform automatic trace context propagation on your behalf. Explore the documentation starting from Akka Integration Overview to understand what it can and how to achieve that.

  这篇关于如何分析Akka应用程序？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！