好久不用Windchill了，近日接到一个朋友的紧急电话，有一个客户遇到了性能问题，非常着急，希望我能去帮忙解决，由于周末就两天时间，太短了，只好硬着头皮去了现场（好在原来优化过很多项目，心里还是很自信的），毕竟两年不用Windchill了，想不到一摸到系统，还是有种很熟悉的感觉，毕竟和我朝夕相处了八年啊。。。
由于时间紧，周六上午过去，周日晚上还要赶回上海，时间搞的相当紧张。下面是这次调优的记录：
现状
由于用户数据量和注册用户数近两年来的增加，系统性能逐渐变慢，尤其是流程任务处理方面，主要表现在：
1． 提交一个零部件（带4个文档）的审批，页面需要10多秒钟才能完成，而且每个审批环节都如此，如果数据量多的话，性能更是慢的不堪忍受。
2． 虽然在去年增加了32G内存，但是这些内存都没有被充分利用
3． 搜索功能性能也不如以前。
分析
1. 检查流程队列，发现只使用了一个队列，所有的任务都在排队处理，当出现数据集中提交的时候，会出现堵塞的情况，尤其是当一个任务出现异常而停顿的时候，其他任务都不能得到及时处理。所以需要增加多个队列。
2. 据用户反映，原来也考虑过增加队列，但是发现签名会出现混乱的情况。经过反复检查代码，发现是由于所有流程的签名文件都叫“signature.txt”造成的，一个队列时，只会有一个进程写该文件，多个队列时，当碰巧多个进程都写该文件时，必然会引起混乱。此问题必须通过修改代码才能实现
3. 检查如下三个流程的时候：**零部件签审流程、**图样单独签审流程，**文档签审流程，发现页面处理逻辑和系统操作逻辑混在一起，造成用户点击“任务完成”按钮的时候，系统需要进行大量的操作，造成用户等待时间非常长，用户体验非常差。此问题必须通过修改流程解决，将页面处理逻辑放在“User Task”里面，而其他操作放在“表达式自动机”里面（用户之前也考虑过该处理方式，但是由于表达式里面不能取到正确的审核者而作罢）。
4. 系统一共使用的内存比两年前并没有增大多少，总共使用的内存大概只有8G左右，而整个服务器的内存已经增加到了32G，需要增加系统可使用的内存。
5. 检查系统日志，并没有发现特殊的错误，和性能有关的只发现“java.net.SocketException: 没有进程来读取写入管道的数据。”错误。该错误需要增加“wt.method.rmi.maxSockets”的大小来解决。
采取的措施
两年前，当系统用户数少的时候，数据量相应的也在一个合理的水平，系统的性能是可以满足要求的，但是目前各种数据量已经增加很多，尤其是数据库已经增加到了36G，如果再不进行调优，那系统将会面临很大的性能问题，尤其是在流程方面，用户的增多，导致系统需要处理的任务也大量增加，单个队列已经远远不能满足要求。
如下图，图1表示调优前的状况，图2表示调优后的状况。
现状
由于用户数据量和注册用户数近两年来的增加，系统性能逐渐变慢，尤其是流程任务处理方面，主要表现在：
1． 提交一个零部件（带4个文档）的审批，页面需要10多秒钟才能完成，而且每个审批环节都如此，如果数据量多的话，性能更是慢的不堪忍受。
2． 虽然在去年增加了32G内存，但是这些内存都没有被充分利用
3． 搜索功能性能也不如以前。
分析
1. 检查流程队列，发现只使用了一个队列，所有的任务都在排队处理，当出现数据集中提交的时候，会出现堵塞的情况，尤其是当一个任务出现异常而停顿的时候，其他任务都不能得到及时处理。所以需要增加多个队列。
2. 据用户反映，原来也考虑过增加队列，但是发现签名会出现混乱的情况。经过反复检查代码，发现是由于所有流程的签名文件都叫“signature.txt”造成的，一个队列时，只会有一个进程写该文件，多个队列时，当碰巧多个进程都写该文件时，必然会引起混乱。此问题必须通过修改代码才能实现
3. 检查如下三个流程的时候：**零部件签审流程、**图样单独签审流程，**文档签审流程，发现页面处理逻辑和系统操作逻辑混在一起，造成用户点击“任务完成”按钮的时候，系统需要进行大量的操作，造成用户等待时间非常长，用户体验非常差。此问题必须通过修改流程解决，将页面处理逻辑放在“User Task”里面，而其他操作放在“表达式自动机”里面（用户之前也考虑过该处理方式，但是由于表达式里面不能取到正确的审核者而作罢）。
4. 系统一共使用的内存比两年前并没有增大多少，总共使用的内存大概只有8G左右，而整个服务器的内存已经增加到了32G，需要增加系统可使用的内存。
5. 检查系统日志，并没有发现特殊的错误，和性能有关的只发现“java.net.SocketException: 没有进程来读取写入管道的数据。”错误。该错误需要增加“wt.method.rmi.maxSockets”的大小来解决。
采取的措施
两年前，当系统用户数少的时候，数据量相应的也在一个合理的水平，系统的性能是可以满足要求的，但是目前各种数据量已经增加很多，尤其是数据库已经增加到了36G，如果再不进行调优，那系统将会面临很大的性能问题，尤其是在流程方面，用户的增多，导致系统需要处理的任务也大量增加，单个队列已经远远不能满足要求。
如下图，图1表示调优前的状况，图2表示调优后的状况。
![clip_image003[4]](http://images.cnblogs.com/cnblogs_com/HeavyMetal/WindowsLiveWriter/cf4a69b6a370_93AF/clip_image003%5B4%5D.gif "clip_image003[4]") |
调优以后的性能
1． 用户完成任务由原来的10秒以上，缩短到1~2秒
2． 增加队列数量为10个后，单个流程任务的处理并没有提高多少，但是由于增加了队列数量，当出现大量任务的时候，性能最快可以提高到10倍。
3． 整体性能的提高：由于增加了整个应用可使用的内存，并且优化了负载平衡的参数，使得处理复杂任务的能力得到提高。
4． 虽然内存并没有使用到全部的32G，但是考虑到该机器上还装有其他系统，所以需要保留一部分，并且调配的内存（18G左右）已经足够使用。
附录：
调整前后参数对照表：
| Oracle | |||
| 参数 | 原始值 | 修改值 | 备注 |
| share pool size | 608 | 1200 | |
| buffer size | 800 | 1952 | |
| large pool | 80 | 192 | |
| pga | 600 | 1200 | |
| 总计 | 2088 | 4544 | |
| Windchill | |||
| 参数 | 原始值 | 修改值 | 备注 |
| method server可用内存 | 1280 | 3000 | 最大最小值改成一样 |
| back ground method server可用内存 | 1280 | 3000 | 同上 |
| server manager可用内存 | 512 | 512 | 同上 |
| wt.cache.size.WTPrincipalCache | 500 | 1200 | |
| wt.method.rmi.maxSockets | 2000 | 3000 | |
| wt.workflow.engine.userWorkPoolSize | 无 | 10 | |
| wt.workflow.engine.propagationPoolSize | 无 | 10 | |
| wt.queue.max.processQueues | 无（默认12） | 50 | |
| wt.queue.execEntriesCount | 无 | 12 | |
| wt.manager.serverSelector.MethodServer | 无 | wt.manager.StandardServerSelector |
修改程序
ext.**.workflow.WF.java
修改流程
| 流程名称 | 原始使用版本 | 修改后的版本 |
| **零部件签审流程 | 23 | 以2010.8.2号修改版本为准 |
| **图样单独签审流程 | 12 | 以2010.8.2号修改版本为准 |
| **文档签审流程 | 17 | 以2010.8.2号修改版本为准 |
图2：调优后的系统状况
调优以后的性能
1． 用户完成任务由原来的10秒以上，缩短到1~2秒
2． 增加队列数量为10个后，单个流程任务的处理并没有提高多少，但是由于增加了队列数量，当出现大量任务的时候，性能最快可以提高到10倍。
3． 整体性能的提高：由于增加了整个应用可使用的内存，并且优化了负载平衡的参数，使得处理复杂任务的能力得到提高。
4． 虽然内存并没有使用到全部的32G，但是考虑到该机器上还装有其他系统，所以需要保留一部分，并且调配的内存（18G左右）已经足够使用。
附录：
调整前后参数对照表：
| Oracle | |||
| 参数 | 原始值 | 修改值 | 备注 |
| share pool size | 608 | 1200 | |
| buffer size | 800 | 1952 | |
| large pool | 80 | 192 | |
| pga | 600 | 1200 | |
| 总计 | 2088 | 4544 | |
| Windchill | |||
| 参数 | 原始值 | 修改值 | 备注 |
| method server可用内存 | 1280 | 3000 | 最大最小值改成一样 |
| back ground method server可用内存 | 1280 | 3000 | 同上 |
| server manager可用内存 | 512 | 512 | 同上 |
| wt.cache.size.WTPrincipalCache | 500 | 1200 | |
| wt.method.rmi.maxSockets | 2000 | 3000 | |
| wt.workflow.engine.userWorkPoolSize | 无 | 10 | |
| wt.workflow.engine.propagationPoolSize | 无 | 10 | |
| wt.queue.max.processQueues | 无（默认12） | 50 | |
| wt.queue.execEntriesCount | 无 | 12 | |
| wt.manager.serverSelector.MethodServer | 无 | wt.manager.StandardServerSelector |
修改程序
ext.**.workflow.WF.java
修改流程
| 流程名称 | 原始使用版本 | 修改后的版本 |
| **零部件签审流程 | 23 | 以2010.8.2号修改版本为准 |
| **图样单独签审流程 | 12 | 以2010.8.2号修改版本为准 |
| **文档签审流程 | 17 | 以2010.8.2号修改版本为准 |
