项目开发性能优化注意事项

 

1） 充分合理利用已有的运算逻辑完成逻辑流的开发，以提高逻辑流处理的效率，以下为常见的原则：

a) 处理数据库查询时，如果很确定需要查询哪些字段，建议使用查询指定字段的运算逻辑，而不是查询所有字段的运算逻辑，尤其在相应表包含的字段数很多而且数据量很大的情况下更应遵循本原则；比如多字段很多的表，可以建立多个不同名称的数据实体，访问字段少的用少量字段的数据实体，访问字段多的用字段多的数据实体来进行不同的查询和更新。

b) 在处理数据库查询时，对于具有海量数据表的操作要求进行谨慎查询处理，避免因条件范围太宽导致返回数据过多，影响系统资源消耗；

c) 对数据库查询、更新进行优化，如对查询where条件建立索引（如外键、唯一性字段、时间字段等）

d) 处理数据库查询时，如果直接使用sql处理查询，避免使用“select * from”语句，建议明确指定查询字段，如“select a,b,c from ...”；

e) 命名SQL的性能高于数据实体操作，必要时可以考虑使用命名SQL；

f) 在处理迭代的情况时，如果迭代的次数非常大引起处理时间无法满足应用要求的响应指标，应该考虑进行处理优化（如减少迭代过程中的处理环节等），或者将该部分的逻辑流处理通过运算逻辑实现；

g) 一般情况下，业务处理的逻辑不建议通过运算逻辑实现，但在某种特定情况下，从平衡效率的角度，需要将业务处理逻辑通过运算逻辑实现，这需要依据经验根据实际情况确定；

h) 在逻辑流实现的处理步骤中，如果某些处理没有顺序上的区分，建议将产生数据量大的处理放在靠后的步骤中，这样可以减少数据总线上数据的容量。例如，某个逻辑流实现查询订单的详细信息和订单的物品列表，这两个查询处理在逻辑上没有先后顺序，则建议将执行后产生的数据量大的处理放在后面处理，所以逻辑流实现时，先查询订单详细信息，再查询订单的物品列表；

i) 逻辑流中允许子逻辑流的嵌套调用，但嵌套的层次最好不要超过3层，否则对事务处理的考虑变得比较复杂，而且嵌套层次太深，会影响执行效率；

j) 尽量避免使用saveEntity，saveEntity要先查询是否有数据，有数据时使用updateEntity，没有时使用insertEntity，会导致性能下降，数据量比较太的时候会导致性能下降较高；建议直接使用insertEntity（如记录DB日志，肯定是插入新操作，用insertEntity就可以了），和updateEntity（如果确认是修改操作）。

k) 本地调用尽量避免调用SCA服务（如果不调用远程服务的话），如Abframe业务框架中登陆功能，应该修改成调用本地的逻辑流；测试中也发现存在二个影响性能的逻辑流；

l) 服务装配中发布的服务分两种方式，SCA服务和WebService服务，他们都是用来提供给远程调用的，如果不需要WebService的话，尽量采用SCA服务，SCA使用二进制数据进行传输，速度大大快于WebService的xml数据传输。

m) 赋值图元尽量少，尽量将多个赋值图元合并成一个，因为每一个赋值图元都会生成一个独立的方法，方法中都会有相同的准备上下文动作，begin和end时会调用拦截器的动作，会消耗性能。

n) 尽量减少不必要的ajax调用（多用于数据校验等），ajax使用xml提交数据，xml解析普遍比对象操作慢，特别是ajax调用中在调用webservice，会存在多次xml序列化和反序列化的操作，影响性能。

o) 获取主键数据源的运算逻辑要放在事务的外面，获取主键是独立的操作，不需要和业务事务绑定在一起。获取主键的缓冲值可以放大，要设置单独的主键数据源EOS-Unique，和业务数据源分开。

p) WebService调用不要放在事务中，因为WebService调用较慢，会造成长时间事务，而使用事务会锁表，长时间的事务会造成锁表问题，影响性能。

q) 尽量不用XA数据源，XA数据源不稳定且bug较多。JTA分布式事务本身就复杂，不稳定，而且要用到DB的两阶段提交，速度慢。

r) jsp开发只在必要时使用eos标签(如需要使用proerty取值的)，不需要时最好用html标签，如<input type=“button”>标签，可以直接使用html的input标签，这样不需要额外的标签解析，速度快。如果没有使用页面流上下文数据，尽量不用h:form标签，而直接使用<form>标签，传action只需要设置_eosFlowAction hidden 字段就可以了。

s) 页面流、逻辑流拦截器（配置到working/eos-default/config/handler-engine.xml文件中）的条件要限制不能太宽，要有针对性，尽量避免match-pattern="*"，这样所有对页面流、逻辑流的调用都会调用拦截器，影响性能。拦截器数量尽量要少。

t) 对于某些逻辑流，比如查询会计日期，会查询数据库，而且会被大量调用，但每天查询的会计日期都是一样的，这样就可以使用运算逻辑将这个值缓存到内存中，直接从内存中去会计日期，而避免频繁查询数据库，可以较大的提高性能。

u) 对于没有返回值的逻辑流调用，或有返回值，但对返回值不做任何处理的，可以使用异步方式进行调用，这样不等待返回结果就可以进行下一步操作，加快进度。异步调用在Tomcat上使用线程方式，即开一个线程进行调用，在JBoss、WebLogic、WebSphere上使用JMS调用消息驱动Bean（即Message Driven Bean，简称MDB,是EJB的一种）进行调用，即发消息给JMS Server，消息会存入消息队列，然后排队发送处理。

v) Java方法中尽量避免使用反射（Reflection）方式调用，反射方式调用速度较慢。

 

2） 多表查询的对策（按优先级排列）：

建立EOS查询实体；

建立数据库视图；

建立命名Sql；

 

3） 运算逻辑参数项设置原则：

a) 不建议运算逻辑设置太多参数项（对于支持多组参数的除外），如果参数项超过5个，建议充分利用SDO对象，通过Entity的节点方式处理，例如发送邮件的运算逻辑sendMail，将整个邮件信息（如发件人、收件人、抄送人、主题、内容、附件等等）放入一个SDO对象中以一个参数传入，而不是每项作为一个参数传入，在运算逻辑中通过取SDO对象的属性获得各项参数。

 

4） 页面流对于Session数据的处理原则：

a) SessionContext数据将在会话期间占用内存，只适合保存会话期间的全局数据，尽可能避免在会话数据中存放过多数据量；

b) 对于MUO对象，由于会自动复制到requestContext和bizContext，更加需要控制存放的数据大小；

 

5） 页面流/逻辑流的图形应该简单明了，如果一个页面流/逻辑流上面出现超过20个以上的图元(不包含开始和结束图元)，则需要考虑该逻辑是否应该优化，如判断是否处理繁琐冗余，是否可以变为多个页面流，是否调用的逻辑流粒度太细等。

 

 

6） 在工作流应用中设计业务表的时候，在业务表中保存流程实例id的字段PROCESSINSTID一定要设计为number或decimal，不然通过根据业务实体查询工作项的查询语句效率会非常慢。因为对数值的处理要比字符串的处理速度快很多。