识别性能瓶颈

着名的计算机科学家唐纳德·克努特（Donald Knuth）说：

“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.“

在浪费任何优化的努力之前，重要的是要确定具体的问题或低效率是第一位的。

确定需要大量SQL或BeanShell脚本的用户视图页面和菜单中的元素。这是性能问题的常见原因。
使用性能分析器来帮助识别应用程序中的慢速元素
利用您的数据库识别您的应用程序中的慢SQL查询，例如对于MySQL，您可以使用慢查询日志
检查您的自定义插件，以确保它们不会引入缓慢的处理，数据库查询等
确定是否有足够的资源（物理内存，存储空间，Java VM分配等）来处理您的应用程序使用情况，以及是否有任何资源泄漏。

一旦确定了潜在问题的位置，就可以开始考虑优化每个区域，如下所述。

确保足够的Java VM内存分配

该平台运行在Java VM（JVM）上，根据应用程序的大小和复杂性以及使用情况，您可能需要调整JVM堆内存大小以适合您的环境。如果设置太低，则系统将耗尽内存，导致OutOfMemory错误。但是，如果该设置与可用物理RAM的数量相比太高，则除了垃圾收集的开销之外，还可能会有相当多的交换。

默认的JVM设置非常低，以支持在用户的个人计算机上进行测试或开发的安装。要获得最佳设置，有时可能需要一些试用和错误，具体取决于使用环境。

您可以使用工具，如VisualVM的监视内存的使用情况按使用VisualVM的监视。

部署最佳实践#JavaVMConfiguration提供了一些额外的细节。

消除资源泄漏（内存，数据库连接，文件，网络等）

在平台层面，Joget Workflow已经过优化和测试，以确保没有资源泄漏。

但是，将这些问题引入您的应用程序是非常可能的。例如，您可能正在创建和使用数据库连接而不关闭它们。这将导致您的数据库连接池耗尽，并最终导致系统停止。在BeanShell脚本或自定义插件中使用自定义Java或JDBC代码时，必须在try-catch finally循环中关闭数据库连接，例如

Connection con = null;
try {
   // get connection
   con = datasource.getConnection();
   
   // more processing
} finally {
   // close connection
   try {
       if (con != null) {
           con.close();
       }
   } catch (Exception e) {
   }
}

同样，任何创建对象，网络连接或文件IO的自定义代码都必须在try-finally块中释放这些资源。未释放的内存指示将显示在Java VM内存使用情况中，这将随着时间的推移不断增加。

使用像VisualVM这样的工具，您将能够监视内存使用情况。

可以在数据库服务器中监视数据库连接的使用情况，也可以使用即将到来的v6 数据库连接监视和泄漏检测功能。

优化您的应用程序和数据库查询

Joget Workflow已经过彻底的分析和优化，以确保平台级别的开销很小。但是，在依赖动态数据的企业应用程序中，每个页面请求都需要许多数据库查询。数据库调用不仅在查询执行中很慢，而且在网络I / O中尤其如此。在大多数情况下，数据库调用是造成冗长的页面响应时间和限制可伸缩性的主要性能瓶颈。

因此，尽量减少在应用程序中进行的数据库调用次数。检查你的应用程序，以确保任何数据库调用（或处理）是真正必要的，如果不删除它们。

这不仅适用于主用户视图页面，也适用于用户视图菜单。例如，在菜单中显示项目计数会导致数据库查询的速度变慢，因此您需要决定是否显示该项目。您可以使用Userview 嵌入式模式来测试带菜单和不带菜单的页面性能。

在即将到来的v6中，将会有一个新的用户视图缓存功能来选择性地缓存用户视图页面和菜单，以显着提升性能。

调整数据库和应用程序服务器

您应该优化在您的应用程序中使用的自定义SQL查询，因为慢速查询是非常常见的瓶颈。例如，在MySQL中，您可以使用EXPLAIN 命令来帮助您确定查询的执行计划，并找到优化它们的方法。

对于需要大量数据库查询的应用程序，您需要优化数据库和数据库服务器配置。根据所使用的数据库服务器的类型，您的数据库管理员将最适合根据您的使用模式执行此类调整。例如，MySQL在文档http://dev.mysql.com/doc/refman/5.6/en/optimization.html中有一个关于优化的部分。

部署最佳实践#DatabaseConfiguration有一些额外的信息。

如果对您的应用程序有大量的并发请求，那么按照部署最佳实践#WebApplicationServerConfiguration调整应用程序服务器也是明智之举。

加载测试您的应用程序和服务器大小

确定有效运行Joget Workflow所需的服务器规格涉及许多因素。这些是一些非决定性的因素：

用户总数
最大预期并发用户数
平台上运行的应用程序的数量
每个应用程序的复杂性
每个应用程序生成的数据量
网络基础设施

例如，运行使用频繁的复杂应用程序的用户数量较少的环境可能比运行一些简单应用程序的用户数量大的环境需要更多资源。

因此，仅根据最大和并发用户的数量，您将无法预测需要什么。通常，安装将首先从单个应用程序服务器开始，然后在需要时进行扩展或集群。

要确定您的应用和使用的实际要求，最好在您的环境中执行负载测试。有许多免费和商业的负载测试可用，有一篇文章使用开源的JMeter工具在 Joget工作流集群和亚马逊网络服务（AWS）上进行性能测试。

介绍集群和负载平衡

在优化应用程序时，可以根据需要增加服务器容量以处理增加的负载（垂直缩放）。您也可以开始考虑执行水平缩放，即对您的安装进行集群或负载平衡。这不仅可以处理增加的负载，而且还提供高可用性。在部署最佳实践#ClusteringandLoadBalancing上阅读更多。

Page tree

Performance & Scalability Tips