Mendix性能最佳实践
目录
- 1. 简介
- 2. 计算属性的最佳实践[MXP001][MXP002]
- 2.1 在页面中避免使用计算属性[MXP001]
- 2.1.1 修复步骤
- 2.2 删除未使用的计算属性[MXP002]
- 2.2.1 修复步骤
- 3. 为排序栏中的属性添加索引[MXP003]
- 3.1 修复步骤
- 4. 避免在循环中创建对象、修改对象或提交活动时提交对象[MXP004][MXP005]
- 4.1 创建或修改对象活动的修复步骤[MXP004]
- 4.2 提交活动的修复步骤[MXP005]
- 5. 将符合条件的微流转化成纳流[MXP006]
- 5.1 修复步骤
- 6. 为用在XPath表达式中的属性添加索引[MXP007]
- 6.1 修复步骤
- 7. 避免缓存非持久化实体[MXP008]
- 7.1 修复步骤
- 8. 避免使用多级继承[MXP009]
- 8.1 修复步骤
- 9. 重复的访问规则[MXP010]
- 9.1 修复步骤
- 10. 避免深度的嵌套列表视图[MXP011]
- 10.1 修复步骤
- 11. 避免重复提交变量[MXP012]
- 11.1 修复步骤
- 12. 否定的XPath实体访问规则[MXP013]
- 12.1 修复步骤
- 13. 将创建/修改/删除活动放在微流的结束事件附近[MXP014]
- 13.1 修复步骤
- 14. 对XPath取和部分的排序:最廉价和最具体的优先[MXP015]
- 14.1 修复步骤
1. 简介
本文概述了Mendix应用的性能问题及Mendix应用性能优化的最佳实践。
2. 计算属性的最佳实践[MXP001][MXP002]
如果对象有计算属性,每次对象从存储中修改或者检索,通过调用微流都会对计算属性进行计算。如果不使用逻辑的结果同时计算属性背后的逻辑又取回其他对象或者执行集成活动,则会导致额外的负载(和延迟)。创建计算属性通常影响性能,因此必须评估是否有必要使用。关于属性更多信息,请参考Attributes。
在多数情况下,计算属性背后的逻辑总是在使用对象时进行执行。只要检索活动没有检索模式(表格(data grid)就是这种情况),就会执行。计算属性背后的逻辑在以下元素中执行:
- 微流中检索和修改对象的活动。
- 在UI组件中(例如,data view或自定义组件)
- 对象从UI中作为参数传递给微流(例如,按钮触发微流)
计算属性导致两种不同的性能问题可被修复:
- 在页面中使用计算属性
- 有未使用的计算属性
2.1 在页面中避免使用计算属性[MXP001]
检索活动触发计算属性的逻辑,导致数据库的操作和微流的调用被执行(对象通过计算属性相互检索)。
如果页面中的数据容器(list view,data view或者data grid)使用计算属性,将影响加载的时间和页面显示的时间。
2.1.1 修复步骤
为解决此问题,参考以下步骤:
- 在领域模型中,将计算属性改为存储属性。
- 在该属性提交到数据库时,使用相关微流计算该属性值。
由于该属性改为存储属性,数据库仅包含该数据类型的缺省值,可能需要迁移已有的数据。
2.2 删除未使用的计算属性[MXP002]
检索活动触发计算属性的逻辑,导致数据库的操作和微流的调用被执行(对象通过计算属性相互检索)。
如果计算属性未被使用,为避免多余的微流调用可以将它们安全的删除。
2.2.1 修复步骤
删除未用的计算属性。
3. 为排序栏中的属性添加索引[MXP003]
排序栏用于对数据容器中的数据项进行排序。排序栏可用在三种不同的数据容器中:
- Data grid
- Template grid
- Reference set selector
在排序栏中的每个排序项依次用来对组件中的数据进行排序。为排序项所用的属性添加索引可使排序过程更加迅速,从而提高页面的性能。
对于实体有四种操作:创建、修改、删除和查询。创建、修改、删除操作的数量多于查询操作的数量称为写密集,因为此种情况下大多数操作会改变数据库中的数据,而不是从中选择;查询操作的数量多于创建、修改、删除操作的数量称为读密集,因为大多数操作都是从数据库中选择数据。优化时,重要的是仅对属于读密集的实体属性进行优化。
由于读密集和写密集的优化完全不同,因此通过对实体操作类型的区分十分有价值。
3.1 修复步骤
为页面中排序栏中用作排序的属性添加索引。
4. 避免在循环中创建对象、修改对象或提交活动时提交对象[MXP004][MXP005]
在微流中,Mendix对象用作数据库持续化有三种活动:Create Object活动、Change Object</