Cognos 8 性能研究
1、容量规划：
对容量的规划意思是确定硬件的需求，能让你的系统总在预定的工作负荷下良好运行。
容量规划是一项挑战，因为它包括许多的可变因素，其中某些是很难或不可能去度量调整。这是一门学科调整已知变量或开发学习评估资源需求在这些度量点的基础上。同时这也是一门艺术让未知变量和评估他们的影响在评估来自于已知的变量。
要确定你的cognos 8服务的容量需求，需要收集以下信息：
1、cognos 8 用户数
评估期望使用cognos 8所提供的服务的用户数，他们期望在什么时间访问cognos 8 服务。
2、应用的复杂度
评估用户要求cognos 8 进行处理的操作的复杂度。
3、你们的应用部署结构
你们环境中特有的应用部署结构。
容量规划是一项不断进行的操作，在cognos 8 部署之后，监控和修改你的容量作为一项需求，以达到性能期望值。
2、估计cognos 8用户负载：
首先，逐渐增长的用户数及单位时间里更集中的请求，要求更多的硬件来满足对性能的不断追求。因此，为cognos 8估计适合的容量，你应该估计多少用户会使用cognos 8并确定什么时候他们使用cognos 8，这样不仅可以帮助你确定需要多少硬件，还可以帮助你使硬件资源得到更合理的利用。
3、估计并发用户数：
只有在cognos 8 上实际的履行操作的用户才对cognos 8产生负载，这就是并发用户。你可以估计并发用户数，基于你们总共的用户数，区别于有身份的、积极活动的、并发的用户数。
1、有身份的用户
有身份的用户是指所有的用户在cognos 8 中授权可以使用的，也就是我们的总用户数。
2、积极活动的用户
它是有身份的用户的一个子集，指那些登录了cognos 8 服务，并且（查询）请求系统资源的用户。
3、并发用户
它是积极活动的用户的一个子集，指那些同时（查询）请求系统资源的用户，包括用户提交请求和用户等待已发出请求的响应结果。
通常，在商业集成应用型系统中有身份的用户、积极用户、并发用户之间的比值约等于100:10:1，也就是说，每1000个有身份用户，其中有100个是积极用户，10个是并发用户。
并发比率会随时间变化而变化，并且受到诸多因素的影响。例如：并发用户数相对于积极用户数、有身份用户数变高，当用户数很小时，但是，决定并发比率最重要的因素是每个操作对系统的查询随时间是如何分布的。
4、估计负载分布：
在cognos 8中，负载产生与以下情形：
1、用户操作和处理请求，比如浏览报表的请求。
2、自动产生或事件驱动的请求，包括计划任务及并发处理的报表。
如何估计用户什么时候最可能使用cognos 8及提交操作请求，我们可以决定什么时候计划任务自动执行。这些提供给我们方法去按时间均匀的分配处理器负载，因此我们可以使系统资源得到最佳的利用，提供最佳的性能。这些的关键是评估在每个时间段，cognos 8可承受或能提供的并发用户数。
因素，诸如上班时间、业务惯例、用户地域分布，能决定并发比率随时间如何变化，及如果选择并确认足够的容量。
一个商业集成用于系统中，请求在一天中分布不是均匀分布的，有一个波峰和波谷并发比率，大多数请求在每天的有限（明确的）时间里进行。例如：如果用户集中在某个时区，这就会产生巨大数量的查询请求在上班时间，跟随着一段时间，服务器承受低用户数量的查询请求。在这种情形下，我们可以管理峰值时段和非峰值时段以分享活动的和非活动处理器或系统资源。我们得设置让计划任务在非峰值时段运行，以此让用户的交互查询检索在峰值时间更好的进行。
另一方面，如果用户分布在不同的多个时区，这个系统的用户负载趋向于分为多个时间，非峰值时段的计划任务执行时间就会减少，在这种情况下，我们可以选择致力于分别提供硬件资源给交互式用户和非交互式用户。
5、分配负载操作的时间规划：
弄清用户负载的分布方式能帮助我们决定什么时候进行自动的批处理操作。批处理计划操作可以应用于以下两种类型的报表：
1、配处理报表
这些报表经常依赖与升级，事件驱动信息。例如当天的销售销售数据。
2、突发报表
这些报表多重用户过滤需求为基础，在预定的计划。突发报表用来通用报表格式被应用到许多容器，但每个容器需要自定义信息。
批处理大多数情况下被用于数据更新在预定和有周期的。例如：一个组织需要当天生产销售报表信息，让它们在每个工作日的开始就可用。如果用户生成这些报表在每天早上，它会对系统产生相当大的负载。如果将这些被数据更新操作触发的报表运行在非峰值时段，在峰值的容量需求就可以降下来。
6、评估应用复杂性：
负载不仅由并发用户数决定，还与用户请求操作的应用复杂度有关，一个请求复杂度越大，这个请求的处理就需要消耗越多的时间。一般而言，在既定的时间段，硬件资源可以处理的简单请求操作比复杂请求操作多。因此，应用复杂度是确定一组硬件配置能支撑多少并发用户数的一个关键因素。
cognos 8服务应用的复杂度依赖与对数据库查询返回结果集数据进行处理的工作量的总和及输出报表的大小、样式格式。报表大小取决于报表的页面数量和存在元素的数量，例如图形。
通过确定峰值时段运行的报表数，提高当接收到用户的请求时报表的运行效率，我们就能提高在峰值时段的性能表现。因为报表模式随时间在改变，评估应用的复杂度、提升报表运行效率，需要持续不断的进行，是一项不间断的工作。
7、规划部署架构：
cognos 8性能同样依赖与特殊的部署架构。理想情况下，cognos 8服务器组件应该部署在100Mb的可用网络中，用户浏览器和Web服务器之间的网络带宽对系统性能的影响不可测量，但是影响是一定的。
用真正的服务器计算机，不要使用快速高性能的PC工作站。真正的服务器计算机会让商业应用运行得更快更稳定，减少服务宕机的可能性。
您的Web和应用服务器是专注的为cognos 8服务还是与别的软件产品共享资源？如果应用共享资源，这些应用也必须被作为一部分容量需求考虑在内。
安装 gateway 组件在服务器上仅供处理Web请求操作，Web服务器设计用来处理许多小请求，应用服务器经常用来处理大的请求。
用gateway方式，许多适合你们的环境。例如，在某些环境下，ISAPI或Apache相比CGI，可以提供更好的性能。
安全认证架构的复杂度也会增加响应时间。随着安全认证复杂度的增加，一个用户请求必须被确认更频繁。例如：如果你通过多重的网络防火墙，每个防火墙必须验证所有通过它的请求，这样会增加完成这次请求所需的时间。另外，如果使用了SSL证书，SSL的加密、解密信息就被加入到了请求和相应数据包的头中，这样就将执行加密、解密操作的时间加入到用户请求响应时间中。
8、规划Content Store（内容存储库）：
Content Store 被Content Manager用来存储所有的cognos 8信息，这些信息可被Content Manager通过Cognos Connection 或第三方Portal访问和管理。Content Store是cognos 8 的核心，并且必须拥有足够的资源来处理操作。要最大化和测量Cognos 8的性能，确保content store拥有足够的资源，以保证它不会变成系统的瓶颈。
Cognos 8 content store的大小依赖于Cognos 8项目数量和大小，比如你需要创建和存储的报表、包、计划任务。随时间变化，用户创建了更多的项目，content store的空间也需要增大。
在确定Content Store所需的空间时，需要考虑以下内容：
1、用户数量：
越大的用户数量，Content Store就需要越多的空间来存储用户运行、存储的报表。
2、需要保存的报表的数量：
保存越多的报表，Content Store越多的空间来存储。为整个组织制作设计的报表或存储在公共文件夹下的报表，经常被复制到用户个人文件夹下。更多的空间需要用来存储这部分增加的报表。
3、保存视图的数量：
保存越多的报表视图，content store就需要越多的存储空间。
4、文件夹个数
Cognos 8的代表性用公共文件夹像给每个用户建立一个或多个文件夹，每个文件夹的描述字符会增加文件夹大小。
5、计划任务的数量
计划任务可以出现在每天、每周、每个星期、每个月。越多的计划任务，需要越多的content store存储空间。
6、FrameWork Manager包的数量
越多的FrameWork Manager包、列表及查询对象的数量，需要越多的存储空间。
9、估计content store 大小示例：
并发用户数影响着content store的大小，因为额外的缓存磁盘空间会分配用来存储报表运行请求，甚至未保存的请求。
在50的并发用户中，大约25%会执行报表，另外75%会查看已保存的执行结果。因此，50个用户中大约有12.5个用户在运行报表。下表提供了一个例子，可以用来估计我们所需要的content store大小。
10、可靠性评估：
可靠性是一个系统能够抵御或从异常状态恢复的能力，比如硬件服务器宕机。所有的cognos 8服务器都内建了错误恢复特性以保证cognos 8可以将意外处理好。
我们可以配置每个cognos 8的组件一提高可靠性。通常的规则是，让每个Cognos 8组件都在至少2台服务器上可用。则可以保证任何一台服务器出现宕机，另外一台可以接管其服务。
假设，因为调优的原因，我们不在某一个Cognos 8服务器上，运行所有的Cognos 8组件，保证每个组件运行在至少2个服务器上。如果出现因为服务器宕机，剩下的可哟功能组件就能处理请求。性能可能会降低，但服务是不会宕机的。
11、Cognos 8 Gateway可靠性：
在Cognos 8中，所有的Web交互都是通过一个安装在Web服务器上的Cognos 8 Gateway完成的，每个Gateway可以在应用组件帮助下，通过简单的分发器互相通信。
我们推荐让Cognos 8使用两个或两个以上的Web服务器，这样保证单个服务器故障不会导致Cognos 8服务丢失。我们也可以用额外的负载均衡器，比如路由来在可用的分发器之间分配请求。
在不可预定的失败事件出现时，Cognos 8 gateway、Cognos 应用防火墙会自动的被Web服务器重新启动。
12、Cognos 8服务可靠性：
Cognos 8 服务包含Content Manager来存储和管理信息、分发器去启动Cognos 8 服务及路由请求。
分发器管理Cognos 8的图像服务、批处理报表服务、报表服务、计划任务监控服务、日志服务。为了保证一个服务的宕机不影响到Cognos 8整体，至少应该安装2个Cognos 8服务器。我们可以交叉分配服务到Cognos 8服务器上，并且我们不需要在一个Cognos 8服务器上启动所有服务。
Cognos 8 所用的Java技术可以让Content Manager 和分发器包含自动错误恢复机制。这两个组件都是多线程的，并且每个线程之间是相互独立的。如果错误出现，它只影响单个的请求线程，如果那个线程失败，别的线程不受到影响，错误不会对整个Cognos 8造成影响。
如果Content Manager或分发器失败，Cognos 8服务会自动重启。如果我们的Cognos 8用了Apache Tomcat servlet容器，Cognos 8 服务会监控和重启Tomcat。如果我们的应用服务器用的不是Tomcat，需要用这个服务器的相应管理方法来重启应用服务器。
13、Content Manager可靠性：
可能在我们的安装方案中，安装了多个Content Manager在不同的机器上。一个Content Manager 服务器是活动的，其他的Content Manager是处于待命状态。待命的Content Manager服务器是用来为错误恢复做准备的。如果活动的Content Manager因为某些软件或硬件的原因而出现错误，待命的Content Manager服务器就会活动起来接管所有活动的请求。
当一个活动的Content Manager失败时，未保存的会话数据会丢失。当另一个Content Manager变为活动状态时，用户要被提示让重新登录。
默认的，第一个与Cognos 8安装的Content Manager就是活动的。Cognos管理员可以在任何时间修改默认的Content Manager和活动的Content Manager。当Cognos 8启动后，默认的Content Manager把Content Store锁定，让别的Content Manager不能存取，其他的Content Manager就进入了待命状态。
这种错误恢复机制建立在分发器与活动的Content Manager之间可以互相通信。如果一个分发器不能连接到Content Manager，分发器发送信号到待命的Content Manager，它就变成了活动的Content Manager。其他的Content Manager仍然处于待命状态，等待错误恢复操作。待命的Content Manager重新从活动的Content Manager中找回加密信息，例如公用对称密钥（用来加密和解密数据）。
14、Content Store可靠性：
Content Manager将Cognos 8信息存储在Content Store这个关系型数据库管理系统中。Content Manager通过合理的事务操作将数据写如Content Store中，我们可以用标准的数据库工具来备份和恢复Content Store的数据，用标准数据库可靠性机制来保证Content Store不宕机。
15、性能监控和调优：
随时间推移，cognos 8 的环境也在发生改变。用户组、处理的请求的数量和复杂度也慢慢增加，网络容量及其他方面也可能被修改过。
这些变化都可能对cognos 8的性能有影响。因此，有规律的监控和调节是一项十分重要的工作。
监控性能是指有规律的检查状态cognos 8的安装情况及资源消耗情况。Cognos 8提供了做法用来检查系统、服务器、分发器、及其他服务。我们可以设定一个开始用例度量来识别什么时候性能相对于某个期望值，出现超过或不足。我们可以配置系统，当性能问题出现时让它提醒管理员应该注意这个问题。
调优包括调节以下几个方面：
1、数据库
让数据库保持最优的查询和报表处理性能。
2、应用服务器
调整应用服务器的内存及各种连接设置，使性能最大化。
3、Web服务器
调节Web服务器是性能最大化。
4、Cognos 8
监控和调节Cognos 8系统的各个方面，使性能趋向最大化。
额外的性能调整是必须的。在某一时刻，性能调优收益会出现逐渐减小。用户群体的扩大、日益增多的业务请求，最终需要我们考虑增加系统容量。要提升Cognos 8的性能，我们从垂直方向上，可以考虑用更好的硬件服务器，从水平方向上，可以考虑增加几个服务器，在服务器之间进行负载均衡。
16、性能度量：
我们可以用一些度量来监控当前的系统性能。我们可以获取整个系统状态，也可以监控单个的服务器、分发器的状态。
例如：我们检查性能度量并关注那些报表服务显示一个红色方块指示器，这代表这个服务处于底的性能表现。我们查看这个报表服务的度量数据，确定有多少个请求在执行队列中等待，超过这一段时间内能处理的请求有多少个。我们就需要立即减少队列中请求的数量。
1、会话度量是监控一个系统中会话数的个数，这个度量用Content Manager来收集。
2、队列度量是监控分发器的能力和在服务队列中保持的请求数。例如：队列度量可以看成是监控是否存在待处理的请求在队列中等待时间太长的情况。
3、JVM度量是用来监控状态信息，一长段时间里，Cognos 8 JVM的内存消耗情况，这些信息由JVM收集。
4、服务请求度量用来监控请求处理时间，请求数量、操作状态、响应时间。这些信息由分发器及消息服务收集。
5、报表服务度量用来监控报表服务操作，监控信息由分发器及消息服务收集。
我们定义阈值来确定资源的性能状态是否性能卓越（绿色指示）、性能均衡（黄色指示）、性能很差（红色指示）。默认情况下，阈值是没有定义的，如果定义了阈值，这些值就保存到了Content Store中。
我们也可以定义一个代理来监控度量性能指标是否超出阈值，当性能指标超出阈值时通知管理员。例如当性能指标超出阈值时发封邮件。当性能指标超出阈值时，调度服务器会在日志服务器中新增一条记录。
17、Cognos 8 调优
我们使用和配置Cognos 8的方式可能影响到它的性能。例如我们可以设计模型和报表时留意性能，为提高性能配置好Cognos 8分发器、服务、计划任务，使系统资源得到最佳的利用。
18、报表和模型设计与性能
在Framework Manager中设计和生成模型，在Cognos 8开发工作流中是一个很重要的步骤。一个模型是用来列出清单结构、增加的，管理元数据来创建报表。为了最佳的Cognos 8性能，一个模型设计人员可以设计模型出指定了带有提示的限定了固定查询操作类型的模型。