什么网站的地图,私域电商平台排名,国内人做韩国网站一般都卖什么东西,快三直播十大平台直播间qt如何捕获应用程序输出有兴趣了解如何使用AppDynamics捕获这些Java性能指标吗#xff1f; 立即开始免费试用 #xff01; 前几篇文章介绍了应用程序性能管理#xff08;APM#xff09;#xff0c;并指出了有效实施APM战略的挑战。 本文通过回顾五个顶级性能指标来构建这… qt如何捕获应用程序输出 有兴趣了解如何使用AppDynamics捕获这些Java性能指标吗 立即开始免费试用 前几篇文章介绍了应用程序性能管理APM并指出了有效实施APM战略的挑战。 本文通过回顾五个顶级性能指标来构建这些主题以评估您的企业Java应用程序的运行状况。 本文专门回顾以下内容 商业交易 外部依赖 缓存策略 垃圾收集 应用拓扑 1.商业交易 商业交易提供了对真实用户行为的洞察力它们捕获了真实用户在与您的应用程序进行交互时所经历的实时性能。 如前一篇文章所述衡量业务交易的绩效涉及全面捕获业务交易的响应时间以及测量其组成层的响应时间。 然后可以将这些响应时间与最能满足您的业务需求的基线进行比较以确定正常性。 如果您仅要评估应用程序的一个方面则建议您评估业务交易的行为。 容器度量标准可以提供大量信息并可以帮助您确定何时自动扩展环境而业务交易则决定了应用程序的性能。 而不是询问应用程序服务器中的线程池使用情况您应该询问您的用户是否能够完成其业务交易以及那些业务交易是否正常进行。 作为一点背景业务交易由它们的入口点来标识这是与启动业务交易的应用程序的交互。 可以通过诸如Web请求Web服务调用或消息队列中的消息之类的交互来定义业务交易入口点。 或者您可以选择基于URL参数为同一Web请求定义多个入口点或者根据其正文内容为服务调用定义多个入口点。 关键是业务交易需要与对您的业务有意义的功能相关。 一旦确定了业务交易便会在整个应用程序生态系统中衡量其性能。 对照其基线评估每个单独业务交易的绩效以评估正常性。 例如我们可以确定业务交易的响应时间是否比行为异常的基线的平均响应时间慢两个标准偏差。 图1根据基准评估BT响应时间 用于评估业务交易的基准在业务交易运行的小时数内是一致的但是通过每次业务交易执行来完善业务交易。 例如如果您选择的基准将一天中的某小时和一周中的某天的平均响应时间与业务交易进行比较则在当前时间结束后该小时内执行的所有业务交易将被合并到该基准中下周。 通过这种机制应用程序可以随着时间的推移而发展而无需丢弃和重建原始基准。 您可以将其视为随时间推移的窗口。 总而言之业务交易是对用户体验的最具反映性的度量因此它们是要捕获的最重要的指标。 2.外部依赖 外部依存关系可以有多种形式依存的Web服务遗留系统或数据库 外部依赖关系是您的应用程序与之交互的系统。 我们不必控制在外部依赖项中运行的代码但是我们经常可以控制那些外部依赖项的配置因此了解何时以及何时运行得很好很重要。 此外我们需要能够区分应用程序中的问题和依赖关系中的问题。 从业务交易的角度来看我们可以识别和衡量外部依存关系在它们自己的层中。 有时我们需要配置监视解决方案以识别真正包装外部服务调用的方法但是对于常见协议例如HTTP和JDBC可以自动检测到外部依赖关系。 例如当我在一家保险公司工作时我们拥有一台AS / 400并且使用专有协议与之通信。 我们将方法调用确定为外部依赖项并将其执行归因于AS / 400。 但是我们也有可以为我们自动识别的Web服务调用。 与业务交易及其组成的应用程序层类似应将外部依赖行为作为基准并根据这些基准评估响应时间。 业务事务为您提供了应用程序性能的最佳整体视图可以帮助您处理性能问题但是外部依赖项可能会以意想不到的方式对应用程序产生重大影响除非您正在观察它们。 3.缓存策略 从内存中服务对象总是比通过网络调用从数据库等系统中检索对象要快。 缓存提供了一种在本地存储对象实例的机制从而避免了这种网络往返。 但是如果配置不正确则缓存可能会带来自身的性能挑战。 常见的缓存问题包括 将太多数据加载到缓存中 缓存大小不正确 我与一群不喜欢一般对象关系映射ORM工具特别是不喜欢Level-2缓存的人一起工作。 共识是ORM工具在决定将哪些数据加载到内存中时过于宽松并且为了检索单个对象该工具需要将大量相关数据图加载到内存中。 当正确配置工具时他们对这些工具的担心几乎没有根据但是他们发现的问题是真实的。 简而言之当应用程序只需要该数据的一小部分时它们就不喜欢将大量相互关联的数据加载到内存中。 在衡量高速缓存的性能时需要确定加载到高速缓存中的对象数然后跟踪正在使用的那些对象的百分比。 要查看的关键指标是高速缓存命中率和从高速缓存中弹出的对象数。 高速缓存命中计数或命中率报告从高速缓存中服务的对象请求的数量而不需要进行网络行程来检索对象。 如果高速缓存很大则命中率很小低于10或20并且您看不到从高速缓存中弹出许多对象那么这表明您正在向高速缓存中加载太多数据。 换句话说您的缓存足够大不会抖动请参阅下文并且包含许多未使用的数据。 测量缓存性能时要考虑的另一个方面是缓存大小。 如上例所示缓存是否太大 缓存是否太小 还是缓存大小合适 调整缓存大小时的一个常见问题是无法正确预期用户的行为以及缓存的使用方式。 让我们考虑配置为承载100个对象的缓存但该应用程序在任何给定时间需要300个对象。 前100个调用会将初始对象集加载到缓存中但随后的调用将找不到他们要查找的对象。 结果缓存将需要选择要从缓存中删除的对象以便为新请求的对象腾出空间例如使用最近最少使用LRU算法。 该请求将需要通过网络执行查询以检索对象然后将其存储在缓存中。 结果是我们花费更多的时间来管理缓存而不是服务对象在这种情况下缓存实际上是在阻碍而不是提高性能。 由于Java的性质以及它如何管理垃圾回收进一步加剧了问题这种从缓存中不断添加和删除对象的方法实际上会增加垃圾回收的频率请参阅下文。 当您将高速缓存的大小设置得太小并且发生上述行为时我们说高速缓存正在抖动在这种情况下没有高速缓存比抖动的高速缓存更好。 图2试图以图形方式显示。 图2缓存释放 在这种情况下应用程序从缓存中请求一个对象但是找不到该对象。 然后它通过网络在外部资源中查询对象并将其添加到缓存中。 最后缓存已满因此需要选择一个要从缓存中弹出的对象以便为新对象腾出空间然后将新对象添加到缓存中。 有兴趣了解如何使用AppDynamics捕获这些Java性能指标吗 立即开始免费试用 4.垃圾收集 从最初发布到Java所提供的核心功能之一就是垃圾收集这既是福也是祸。 垃圾回收使我们摆脱了手动管理内存的责任完成使用对象后我们只需删除对该对象的引用垃圾回收将自动为我们释放它。 如果您使用的是需要手动内存管理的语言例如C或C 那么您会发现这减轻了分配和释放内存的麻烦。 此外由于垃圾回收器在没有对该内存的引用时自动释放内存因此它消除了在分配内存并在释放内存之前删除对该内存的引用时发生的传统内存泄漏。 听起来像万灵药不是吗 垃圾收集实现了消除手动内存管理并使我们摆脱传统内存泄漏的目标但这样做的代价是有时会很麻烦。 有几种基于您使用的JVM的垃圾收集策略并且不涉及本文的讨论范围但是足以说明您需要了解垃圾收集器的工作方式以及实现垃圾收集的最佳方法。配置它。 垃圾收集的最大敌人被称为大型或完整垃圾收集。 除了Azul JVM之外所有JVM都遭受主要垃圾回收的困扰。 垃圾收集有两种一般形式 次要 重大的 小型垃圾收集相对频繁地发生目的是释放短暂的对象。 它们在运行时不会冻结JVM线程并且通常不会产生重大影响。 另一方面主要的垃圾收集有时也称为“世界停止”STW垃圾收集因为它们在运行时会冻结JVM中的每个线程。 为了说明这种情况是如何发生的我在本书《 Pro Java EE 5性能管理和优化》中提供了一些数据。 图3可达性测试 运行垃圾回收时它将执行称为可达性测试的活动如图3所示。它构造对象的“根集”其中包括每个运行线程直接可见的所有对象。 然后它遍历由根集中的对象引用的每个对象以及由这些对象引用的对象依此类推直到所有对象都被引用为止。 在执行此操作时它“标记”活动对象正在使用的内存位置然后“清除”所有未使用的内存。 更恰当地说它从根集中释放了没有对象引用路径的所有内存。 最后它压缩或整理内存碎片以便可以分配新对象。 次要集合和主要集合取决于Java虚拟机但图4和5显示了次要集合和主要集合在Sun JVM上的运行方式。 图4次要收藏 在次要收集中将在Eden空间中分配内存直到Eden空间已满。 它执行一个“复制”收集器将活动对象可达性测试从伊甸园复制到两个幸存者空间之一到空间和从空间。 然后可以将留在伊甸园中的物体扫走。 如果幸存者空间已满而我们仍然有活动对象则这些活动对象将被移至保管空间在那里只有大集合可以释放它们。 图5主要收藏 最终保有权空间将被填满并运行次要收集但是保管空间中将没有任何空间可复制不适合幸存者空间的活动对象。 发生这种情况时JVM冻结JVM中的所有线程执行可达性测试清除年轻的一代Eden和两个幸存者空间并压缩保有空间。 我们称此为主要收藏。 如您所料堆越大大型集合的运行频率就越低但是当运行时它们比较小的堆花费的时间长得多。 因此调整堆大小和垃圾回收策略以满足应用程序行为很重要。 5.应用拓扑 在前5个列表中要衡量的最终性能组件是您的应用程序拓扑。 由于云的出现应用程序现在本质上可以具有弹性您的应用程序环境可以增长和缩小以满足用户需求。 因此对您的应用程序拓扑进行清单清点以确定确定环境的最佳大小非常重要。 如果您有太多的虚拟服务器实例那么您的云托管成本将会增加但是如果您没有足够的数量那么您的业务交易将会受到影响。 在此评估过程中测量两个指标很重要 商业交易量 容器性能 应该将业务交易作为基准并且您应该在任何给定的时间知道满足基准所需的服务器数量。 如果您的业务事务负载意外增加例如达到正常负载标准偏差的两倍以上则您可能需要添加其他服务器以满足这些用户的需求。 另一个要衡量的指标是容器的性能。 具体来说您想确定是否有任何服务器层处于胁迫状态如果存在则可能需要向该层添加其他服务器。 查看整个层中的服务器很重要因为单个服务器可能由于垃圾收集等因素而处于胁迫状态但是如果层中很大比例的服务器处于胁迫状态则可能表明该层无法支持负载它正在接收。 由于您的应用程序组件可以单独扩展因此分析每个应用程序组件的性能并相应地调整拓扑非常重要。 结论 本文介绍了在评估应用程序的运行状况时可能需要衡量的前五项指标。 总之前五项是 商业交易 外部依赖 缓存策略 垃圾收集 应用拓扑 在下一篇文章中我们将把本系列的所有主题放在一起以介绍AppDynamics实施其APM战略所采用的方法。 这不是一篇营销文章而是对为何做出某些决策和优化以及它们如何为您提供虚拟或基于云应用程序运行状况的强大视图的解释。 有兴趣了解如何使用AppDynamics捕获这些Java性能指标吗 立即开始免费试用 翻译自: https://www.javacodegeeks.com/2015/05/top-5-java-performance-metrics-to-capture-in-enterprise-applications.htmlqt如何捕获应用程序输出
