【cognos经验杂谈】Cognos报表性能问题的诊断过程

一、Cognos报表性能的诊断过程

之所以把问题定义放在首要位置正是因为当前对Cognos性能问题的定义普遍的非常模糊，比如有人认为10秒钟要慢，有人认为15秒钟叫快，描述口径的不一致为设计开发阶段就埋下了祸根。
1、什么叫性能问题


如上图所示，对于Cognos来说，请求一般分成内容请求和报表请求，报表请求又分基准响应、并发响应、吞吐能力几个方面，对于传统的交易系统而言，每当用户描述性能问题就会被直截了当的定位在并发响应或者吞吐能力上。
      然而不幸的很，面对Cognos报表应用，我们面临最多的往往是基准响应。究其主要原因，主要是传统交易系统是基于过程语言的，开发设计者对内部执行过程非常了解，而像Cognos这样的应用基本上是基于结构化查询基础上的进一步抽象，加上产品本身的开放程度，导致开发设计人员对其内部执行过程了解甚少，单交易请求性能低下的现象比比皆是；其次，查询类应用的数据操作规模往往是传统交易的几十倍甚至成千上万倍；最后，由于该类应用对数据的依赖性非常大，在开发，甚至是测试环节的数据量达不到的情况下开发人员可能不会及时发现这个问题；
     如果把过程语言的开发比成自动挡的汽车，那么我们可以把Cognos这样的产品比成自动挡的汽车，通常情况下而言，自动挡的耗油会大于手动挡。
     显然，如果把Cognos性能问题想当然的定位在吞吐能力（TPS）或者并发响应问题无异于南辕北辙，因为这种出发点会引导问题处理人员把关注点集中到设备配置、系统部署、参数调整等方面上，最终导致问题得不到解决，这种根本性的误解甚至出现在很多资深人士身上。
2、到底多少叫快多少叫慢
    这个问题一直非常模糊，最早提出性能问题的一般是最终用户，最终用户的专业知识等原因决定了他们必然会采用感性的词语来表达性能问题，比如慢、非常的慢、像乌龟或者像蜗牛，并且，由于最终业务用户的位置，一般这些富有感情色彩的表达很快传达到决策层的耳朵里，必然会给开发设计人员带来非常大的压力，如果这个时候技术人员和最终用户在同一问题的理解上存在分歧或者不一致，则会影响整个团队的和谐氛围，出现互相抱怨等糟糕的场面。
    为了避免这个问题，最好的策略就是“先君子后小人”，即采用先进的SLA策略，在非功能分析阶段就明确每张报表的预期执行时间，并且必须精确到秒，这些对性能的精准描述作为设计阶段、开发阶段、测试阶段、试运行阶段所有技术决策的重要依据用来衡量是否能够活着是否达到了这个预期目标。
    同时，当明确定义了性能指标后，分析设计人员可能会对需求在此评估，衡量在现有技术背景下，功能和非功能指标是否能够同时达到，如果能够达到，那么需要投入的成本是多少，用户是否需要考虑性价比？

二、Cognos报表执行过程


该过程也已经描述过，需要再次说明的是，虽然有些环节在某一个组织或者在某个特定阶段是造成问题的主要环节，但是任何一个环节都是能够造成问题的环节！

三、Cognos性能持续改进


不管是个人还是组织，都有义务将已经发现的问题或者已经获得的经验进行提炼归纳，形成一个有用的Checklist，以便同样的问题不出现两次！