Agile PLM 界面操作变慢优化

问题描述

在Agile PLM的浏览历史中无论点任何对象响应都比之前慢好几秒。例如：物料查询，变更查询，历史记录查询等。

变更状态切换变慢，有的时候要等几分钟。

原因分析

1. 随着系统使用时间变长，数据量会增长。查询需要的时间可能会变长，载入的数据量也可能会变大。
2. 在线用户数增长，同时使用系统功能的人数变多。可以适当调高weblogic的内存占用。
3. Weblogic缓存可能变大，日志文件可能会变大。曾经遇到过几次，access日志达到好几G。
4. 增加的事件程序和进程扩展变多，也会导致系统变慢。这种变慢就要具体分析操作对应的扩展程序了。例如：有的进程扩展会查询受影响物件的使用位置或者多级BOM，如果程序没有优化好，会有严重的性能问题。

解决方案

针对不同的原因采取不同的解决方案。通常有以下几种优化方式。

1. 如果是Weblogic缓存目录变的很大。可以删除缓存然后重启。缓存目录：D:\Agile\Agile936\agileDomain\servers\服务名，删除tmp和cache目录。
2. 如果是access日志文件过大，可以尝试将修改日志切换的大小或者改成按时间来生成。
3. 如果是在线用户数或者是载入数据量变大了，可以将weblogic的缓存调大。weblogic默认内存大小是3G，最大可以调到物理内存的一半。也可以将weblogic的并发线程数调大。
4. 如果是数据库数据量变大，也可以考虑加入索引或者调整Oracle的参数。这个建议参考数据库优化方面的文章对数据库优化有一定经验的人来实施。
   1. 对于Agile来说，数据库字段都是动态的，所以加索引尽量不要给第二页和第三页的字段加索引。
   2. Agile系统出厂时已经加了一些必要的索引了，尽量不要改动已存在的索引尤其是全文索引
   3. 索引加的太多会影响新增，修改和删除操作，请一定要谨慎。建议优先考虑联合索引。
   4. 任何改动建议写成脚本，先在测试环境执行，验证后再在正式环境执行。
5. 如果是进程扩展或者事件程序性能问题，那需要挨个排查。这里提供一下优化思路：
   1. 对于查询类的程序如果查询的是相同对象建议写在一起，而不是分成好多个。尤其是对BOM和使用位置的查询。
   2. 如果要做复杂校验，对表结构比较熟尽量使用SQL而不是Agile API来实现。目前对于受影响物件的多级BOM或者使用位置都是可以通过SQL来实现的。具体细节可以参考我的其他文章或者加我微信。（微信号同博客号）
   3. 对于不是特别重要的事件程序，可以将触发类型改成“后”，这样就不会阻塞Agile本身的事务操作。对于执行顺序没有依赖性的程序，可以将订户的执行模式配置成“异步”。这样Agile会新建不同的线程去处理程序。改变之后也可以考虑在程序中加入异常通知邮件。