Table of Contents style circle
Identify Performance Bottlenecks
The saying from renowned computer scientist Donald Knuth goes:
...
识别性能瓶颈
着名的计算机科学家唐纳德·克努特（Donald Knuth）说：
“We “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%.”
Before wasting any effort on optimization, it is important to identify where the specific problems or inefficiencies are first.
Identify elements in your userview pages and menu that requires significant amounts of SQL or BeanShell scripts. These are the common causes of performance issues.
Use the 性能分析器 to help identify the slow elements in your app
Identify slow SQL queries in your app by leveraging on your database e.g. for MySQL you can use the Slow Query Log
Check your custom plugins to ensure that they do not introduce slow processing, database queries, etc.
Identify whether there are sufficient resources (physical memory, storage space, Java VM allocation, etc) to handle your app usage, and whether there are any resource leakages.
...
Ensure Sufficient Java VM Memory Allocation
The platform runs on the Java VM (JVM), and depending on the size and complexity of your apps and usage, you might need to tune the JVM heap memory size to suit your environment. If the setting is too low, the system will run out of memory resulting in OutOfMemory errors. However if the setting is too high compared the amount of physical RAM available, there might be quite a lot of swapping, in addition to overheads in garbage collection.
The default JVM settings are quite low to support installation on a user’s individual computer for testing or development. To get an optimum setting might require a bit of trial and error sometimes, depending on the usage environment.
You can use tools like VisualVM to monitor the memory usage as per Monitoring using VisualVM.
Some additional details are available at 部署最佳实践#JavaVMConfiguration.
Eliminate Resource Leakage (Memory, Database Connections, Files, Network, etc)
At the platform level, Joget Workflow has been optimized and tested to ensure that there are no resource leakages.
“
在浪费任何优化的努力之前，重要的是要确定具体的问题或低效率是第一位的。
确定需要大量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循环中关闭数据库连接，例如However, it is very possible to introduce these problems into your app. For example, you might be creating and using database connections without closing them. This would cause your database connection pool to be exhausted, and eventually cause the system to grind to a halt. When using custom Java or JDBC code in a BeanShell script or custom plugin, database connections must be closed in a try-catch finally loop e.g.
| Code Block |
|---|
Connection con = null;
try {
// get connection
con con = datasource.getConnection();
// more processing
} finally {
// close connection
try try {
if if (con != null) {
con con.close();
}
} catch (Exception e) {
}
} |
...
同样，任何创建对象，网络连接或文件IO的自定义代码都必须在try-finally块中释放这些资源。未释放的内存指示将显示在Java VM内存使用情况中，这将随着时间的推移不断增加。
使用像VisualVM这样的工具，您将能够监视内存使用情况。
可以在数据库服务器中监视数据库连接的使用情况，也可以使用即将到来的v6 数据库连接监视和泄漏检测功能。
...
优化您的应用程序和数据库查询
Joget Workflow已经过彻底的分析和优化，以确保平台级别的开销很小。但是，在依赖动态数据的企业应用程序中，每个页面请求都需要许多数据库查询。数据库调用不仅在查询执行中很慢，而且在网络I / O中尤其如此。在大多数情况下，数据库调用是造成冗长的页面响应时间和限制可伸缩性的主要性能瓶颈。
因此，尽量减少在应用程序中进行的数据库调用次数。检查你的应用程序，以确保任何数据库调用（或处理）是真正必要的，如果不删除它们。
这不仅适用于主用户视图页面，也适用于用户视图菜单。例如，在菜单中显示项目计数会导致数据库查询的速度变慢，因此您需要决定是否显示该项目。您可以使用Userview 嵌入式模式来测试带菜单和不带菜单的页面性能 。
在即将到来的v6中，将会有一个新的用户视图缓存功能来选择性地缓存用户视图页面和菜单，以显着提升性能。
...
调整数据库和应用程序服务器
对于需要大量数据库查询的应用程序，您需要优化数据库和数据库服务器配置。根据所使用的数据库服务器的类型，您的数据库管理员将最适合根据您的使用模式执行此类调整。例如，MySQL在文档
...
Using a tool like VisualVM, you will be able to monitor the memory usage.
The database connection usage can be monitored in your database server, or using the upcoming v6 Database Connection Monitoring and Leak Detection feature.
Optimize your App and Database Queries
Joget Workflow has been thoroughly profiled and optimized to ensure that there is minimal overhead at the platform level. However, in enterprise apps that rely on dynamic data, each page request would require many database queries. Database calls are slow not just in query execution, but especially in network I/O. In most cases, database calls are the main performance bottlenecks that cause lengthy page response times and limit scalability.
It is therefore significant to minimize the number of database calls that are made in the app. Check through your app to ensure that any database calls (or processing) are really necessary, if not remove them.
This also applies not just to the main userview page, but also in the userview menus. For example, displaying a count of items in the menus incur a potentially slow database query, so you need to make a decision on whether or not to display it. You can test the performance of a page with and without menus by using the Userview 嵌入式模式.
In the upcoming v6, there will be a new Userview Caching feature to optionally cache userview pages and menus for a significant performance boost.
Tune the Database and Application Server
For apps that require a lot of database queries, you would want to optimize both your database and database server configuration. Depending on the type of database server used, your database administrator would be best placed to perform such tuning based on your usage pattern. For example, MySQL has a section on optimization in the documentation http://dev.mysql.com/doc/refman/5.6/en/optimization.html.
There are some additional information at 部署最佳实践#DatabaseConfiguration.
If there are a lot of concurrent requests to your app, it might also be prudent to tune your application server as per 部署最佳实践#WebApplicationServerConfiguration.
Load Test your App and Server Sizing
There are many factors involved in determining the server specifications needed to run Joget Workflow effectively. These are some of the non-conclusive factors:
Total number of users
Maximum expected concurrent users
Number of apps running on the platform
Complexity of each of the apps
Amount of data generated in each app
Network infrastructure
For example, an environment with a small number of users running a heavily-used complex app might require more resources than an environment with large number of users running some simple apps only once a day.
So based only on number of maximum and concurrent users, you wouldn't be able to predict what is needed. Usually installations would start with a single application server first, and scale up or cluster when necessary.
To determine the actual requirement for your app and usage, it is best to perform load testing in your environment. There are many free and commercial load testing available, there is an article using the open source Apache JMeter tool at Joget Workflow Clustering and Performance Testing on Amazon Web Services (AWS)
Introduce Clustering and Load Balancing
html中有一个关于优化的部分。
部署最佳实践#DatabaseConfiguration有一些额外的信息 。
如果对您的应用程序有大量的并发请求，那么按照部署最佳实践#WebApplicationServerConfiguration调整应用程序服务器也是 明智之举。
...
加载测试您的应用程序和服务器大小
确定有效运行Joget Workflow所需的服务器规格涉及许多因素。这些是一些非决定性的因素：
用户总数
最大预期并发用户数
平台上运行的应用程序的数量
每个应用程序的复杂性
每个应用程序生成的数据量
网络基础设施
例如，运行使用频繁的复杂应用程序的用户数量较少的环境可能比运行一些简单应用程序的用户数量大的环境需要更多资源。
因此，仅根据最大和并发用户的数量，您将无法预测需要什么。通常，安装将首先从单个应用程序服务器开始，然后在需要时进行扩展或集群。
要确定您的应用和使用的实际要求，最好在您的环境中执行负载测试。有许多免费和商业的负载测试可用，有一篇文章使用开源的JMeter工具在 Joget工作流集群和亚马逊网络服务（AWS）上进行性能测试。
...
介绍集群和负载平衡
在优化应用程序时，可以根据需要增加服务器容量以处理增加的负载（垂直缩放）。您也可以开始考虑执行水平缩放，即对您的安装进行集群或负载平衡。这不仅可以处理增加的负载，而且还提供高可用性。在部署最佳实践#ClusteringandLoadBalancing上阅读更多 。When you have optimized your apps, you can increase your server capacity as appropriate to handle increasing load (vertical scaling). You can also start to consider performing horizontal scaling i.e. to cluster or load balance your installation. This can not only handle increased load, but also offer high availability. Read more on this at 部署最佳实践#ClusteringandLoadBalancing.