应用程序性能和反模式

您选择的任何应用程序都存在一些问题-大小不一。 会有粘贴粘贴的代码，错误，算法，可以更好地考虑一下。 但是，将反模式与这些常规错误区分开来的是，像反模式一样，这些反模式在整个代码库中都不断出现。 根据我最近在处理性能问题方面的经验，我观察到某些反复出现的主题正在破坏整体应用程序的性能。 这些反模式中的大多数都有很好的文档记录，但似乎我们没有从其他错误中学到东西。 我们需要犯自己的错误。 我在叙述最近几个月我观察到的一些常见模式。

• 过多的分层 –大部分基础性能始于过多的分层反模式。 应用程序设计已经随着控制器，命令和外观的使用而增长。 为了使每一层脱钩，设计师在每一层都增加了立面。 现在，对于Web层上的每个请求，该请求调用都经过多个层，以获取结果。 想象一下，对成千上万的请求以及JVM处理这些请求所需的负载执行此操作。 进行这些调用时创建和销毁的对象数量增加了内存开销。 这进一步限制了每个服务器节点可以处理的请求数量。

  根据应用程序的大小，部署模型，用户数量，需要做出适当的决定以减少层数。 例如，如果整个应用程序都部署在同一个容器中，则无需创建多个层的过程Bean，服务Bean（业务Bean），数据访问对象等。类似地，在开发Internet规模的应用程序时，大量的层开始给请求处理增加了开销。

  请记住，大量的层意味着大量的类，这些类实际上开始影响整个应用程序的可维护性。

• 往返 -随着ORM映射，会话/ DAO对象的出现，程序员开始为每个数据调用bean。 这导致层之间的过多调用。 另一个问题是，每个层开始必须支持该模型的方法调用的数量。 更糟糕的情况是，当bean基于Web服务时。 在单个用户请求内进行多个Web服务调用的客户端层将直接影响应用程序性能。

为了减少往返，应用程序需要在业务层处理或合并多个请求。

• 会话过多 -会话对象是JEE容器提供的一项功能，用于在网站访问期间跟踪用户会话。 该应用程序的初衷是在会话中放入非常少的信息，但是在一段时间内，会话对象不断增长。 会话对象中填充了太多数据或错误类型的数据。 大数据对象将意味着放置在会话中的对象将持续存在，直到会话对象被销毁为止。 这影响了应用程序服务器节点可以服务的用户数量。 此外，我已经看到，应用程序使用会话群集来支持可用性要求，但会增加网络流量的开销，并增加应用程序处理更多用户的能力。

  要取消填充会话对象，请清点所有内容，查看有什么必要，哪些对象可以默认请求作用域。 对于其他对象，在使用结束后将其从会话中删除。

• 黄金锤子（一切都是服务） –随着SOA的出现，存在将业务服务公开化的趋势，这些业务服务可以编排为流程服务。 在较旧的应用程序中，可以观察到使用EJB实现的类似模式。 这种模式有时与自下而上的设计方法相结合，意味着将每个数据实体都公开为业务服务 。 这种设计可能在功能上正常运行，但是从性能和维护的角度来看，它很快就变成了夜马。 每个Web服务调用都会增加数据序列化和反序列化的开销。 有时，随Web服务调用一起传递的数据（XML）也很大，从而导致性能问题。

  服务或ejb的使用应从应用程序使用的角度进行评估。 需要注意合同设计。

• Chatty服务 –观察到的另一种模式是通过多个Web服务调用实现服务的方式，每个Web服务调用都在传递一小部分数据。 这导致Web服务爆炸，并导致性能下降和代码无法维护。 同样，从部署角度来看，该应用程序也开始遇到问题。 我遇到过具有数百项服务的项目，所有这些服务都挤在一个部署单元中。 当应用程序启动时，基本堆要求已经在2Gb范围内，没有太多空间供应用程序运行。

  如果应用程序具有太多的细粒度服务，则表明该反模式的应用。

上面提到的反模式是应用程序性能问题的常见原因。 团队通常以正确的意图开始，但是随着时间的流逝，事情将会开始下滑。 一些常见原因

• 缺乏设计标准和审核流程–即使存在这些标准，交付压力也导致跳过这些流程
• 团队成员缺乏经验或视野狭窄，导致每个程序员只看他们的模块，而没有人看整个应用程序的性能
• 不与PMD，Checkstyle，FindBugs等合规性检查工具集成的持续集成（CI）工具
• 在代码构建阶段不专注于定期对应用程序进行性能分析
• 不评估负载测试的结果来破译和解决潜在问题（归咎于基础架构设置不佳）

您还观察到哪些其他反模式导致应用程序性能下降。 分享！

参考： Tech Spot博客上来自我们JCG合作伙伴 Munish K Gupta的应用程序性能和反模式 。

翻译自: https://www.javacodegeeks.com/2012/05/application-performance-and.html