此次出差测试虽然发现了不少问题，如JVM、weblogic参数调整、informix参数调整以及应用代码优化等问题，最终在项目组共同努力下都完成解决。对于我来说这次出差收获确实蛮大的，因为一些测试技术协议以及数据库方面确实是第一次使用，挑战性比较大，但是也学会了不少东西，让我自身的性能测试分析优化提升了不少。
如FLEX协议的测试本人也是第一次接触，一开始接触确实有点手忙脚乱的，估计是做久了HTTP协议了，对其他协议有点恐惧了，在做系统关联时一开始确实不知所措，例如对A用户创建好用户B用户根据该任务编号进行操作 这时需要在脚本中做关联取数然后保存到临时变量、有些还要进行类型转化，在当作参数传值给B用户使用，B用户使用好后，在对该任务进行加工，在传值给C用户这样流程下来，很多结合C语言来实现，而且新的协议工具支持性不是很好，脚本录制下来还要做其他的维护工作，还要做很多参数化，如身份证都是唯一的，200用户并发创建任务，如果跑稳定性测试，至少要几十万笔的身份证，每次都要不一样，这时就要做好参数化设置，每次轮循取值不一样，而且不能超过18位，等等。确实够呛的不过算是重新认识了一门新协议使用，比以前的AJAX协议好玩多了，但是最终发现做了银行类的那么多系统，能用LR进行测试的大部分协议都差不多，实现不了的用C来协助都可以实现。
这次出差对工具使用的感慨是，其实用法差不多，只要静下心不自乱阵脚，什么问题多能解决。就这样这个问题困恼他们项目那么长时间的问题，被我终于解决了，而且还顺便跟玩HTTP协议那样，顺便把FLEX几个常用的函数也使用了下，发现大同小异。可能是我用的少，估计以后碰到其他难题在继续深入研究。
由于之前测试人员测试策略部分错误问题，导致了产生一些不必要性能问题，但是由于这些问题的产生，客户方请来了oracle BEA专家，来协助解决问题。如测试人员使用一些登陆用户在做任务创建测试，结果测试了多次下来，每个登陆用户手头上上都有几万笔的待办任务，而刚好他们也是用这些用户来做测试登陆退出交易测试，加上系统实际业务是每个用户登陆都要进行查询自己手头上的待办任务，200用户并发测试登陆退出，都要进行对自己手头上的几万笔数据进行检索，虽然有后台分页，每次就查10笔，但是也是要对数据库进行很大的开销，那时我刚出差过去第二天，在熟悉系统业务，也在研究FLEX协议，还没真正加入测试，看他们结果测试人员、开发人员整天都围着专家在研究登陆退出性能问题的诊断优化分析，然后频繁的复测，挺热闹的，那天下班看他们还在围观，我也好奇过去看热闹，问了才知道他们是在针对登陆退出系统进行并发优化测试，于是我好奇的看了下，他们操作，发现他们登陆退出手头上的待办任务太多了，就跟测试人员说下，问题可能是登陆用户问题不是技术问题，问了项目经理，实际业务每个人手头上的待办任务最多多少笔，一了解，最大十来笔数据，因为我测试了银行类系统大大小小二十来个，银行业务也有所了解，不可能一个人的待办任务那么多，那要做到何年马月才能做完，而且银行跟钱打交道的，能尽快发放贷款收取利息等才是银行的财源。所以不会那么多待办任务，就这样让该测试人员重新构造测试数据后，问题解决了。
那时看了那位专家针对次问题做一些参数优化，确实不知道怎么说，可能个人见解不一样吧。如xss设置为1024M，我是觉得忒大了，1024K我都觉得大了，反正后来我自己调优测试，改为512K了。还有JDBC连接数 设置为400，我感觉能超过200就太大了，就200用户并发，而且还有工作流等服务，实际用不了那么大，这样对系统产生更大的负荷，划不来，那时我针对专家优化后的参数进行各个交易测试了一遍，以及我自己对各个参数调整后同样场景复测一遍，感觉还是我优化后的比较合理，性能比较好几倍。
---------只是个人见解不一样，我在最终报告是有说明专家的优化配置以及结果，和我的优化结果给项目做对比也提出我的看法给项目领导，最终取哪种看项目决定。
在informix数据库分析优化上，从这个项目确实学习了不少东西，如数据库的性能监控分析优化等命令。优化方式都有所长进。主要是碰到了该项目的我们公司的项目经理，确实是informix优化高手，我在测试过程中碰到很多性能问题，他都能第一时间解决，如磁盘使用100% 内存使用100%等问题都在第一时间内让他解决了，当然从他手头上也学会了为后期项目受用。
对于本次测试结果与oracle一些优化建议产生歧义做了记录，抽取如下几点介绍，因为问题不少没办法都一一介绍，只能说每个人的想法不一样，以下他提出的一些看法跟我见解不一致，例如
一：
JVM配置上专家是设置为2048M，但是我觉得64位的JDK虽然厂商说支持超过了2G，但是我测试多个项目发现实际都没超过1.8G 有问题还是照样出故障，设置太大没用，倒不如腾点空间多做一个实力等。所以我自己决定最终调整为1536M。
二：年轻代，专家是建议调整大一些，这样的好处是减少年轻代对象频繁移到年老代次数，这样说法是合理但是我觉得总大小不变，年轻代大小变大， 年老代就变小，而一般系统FULLGC的时间尽量比较长时间一次如十来分钟一次甚至更长，只能要能回收就好，当然不会FULLGC而内存使用一直正常最好，但是没那么乐观，修复代码成本很大，而且此次测试时间有限，在做优化改代码在测试时间来不及，所以暂时通过调整参数来解决问题了，因此我认为如果缩短年老大大小就会加快FULLGC时间，而我们系统应用测试24小时，前十几个小时FULL是大于15分钟，但是后期都是10分钟。所以从一开始专家没设置年青代大小，后来我调整为512M 再调为 700M 最后调整为600M。
三：系统在测试过程中由于老是受其他项目影响，频繁做system.gc，专家建议是加入禁止系统频繁做system.gc操作参数，我认同他的看法加上去了，但是希望项目组能抽出时间检查是否代码有编写 system.gc 如果有请从代码去除。不然即使从加入参数方式禁掉，还是或多或少有点性能影响。
等等。
也许每个人对调优的见解不一样，最终能解决问题就行，但是我习惯从实际系统业务角度出发结合测试进行分析在解决问题。如果单从技术角度解决问题，在某种程度上是可以，这样不影响业务使用，但是有时由于测试场景问题，导致一序列的性能问题产生，但是针对次问题，就不断的加大各个参数值来解决此问题，得不偿失。
就像医学方面，如果你不小心得了胃病，西医可能给你开个西药一下子就把你的胃病治好了，见效快，但是后期呢，你的肝肾脾也因为吃了西药收不到不同成都的损耗，虽然你胃不疼了，但是你整个身体体质抵抗力等受到不同程度的破坏了，体质变差了，有时吃完药的感觉就是口干舌燥，全身发软没力气，最终只能猛喝水，多睡觉很长的时间才慢慢恢复体质。但是中国的中医就不一样了，吃了中药不一定马上见效，但是它是通过阴阳调整，把我们人体整个体质抵抗力等都调整好，各个器官功能头调整好方式，慢慢的通过你自身的体质来医好胃病。这样达到最终整个身体健康。
系统调优也是同样道理，不能因为解决一个性能问题，而随意调整一些参数值来解决次问题，有时如果是配置不合理通过这样调整是能达到最优效果，但是如果不是这样呢，而是其他问题引起如测试策略本身问题，或者代码问题等，这时你通过加大一些参数也许会反其道而行之，这样最终整个系统会变得更慢，或者更多的硬件资源才能解决此问题。------------纯属个人愚见，欢迎高手点评！