1.4 - 确保JRE Client Side Caching是打开的
在遇到JRE性能问题的时候,第一件事情需要确认的就是JRE Caching是打开并WORKING的。有很多JER性能问题是由于JRECaching被禁止或者配置错误造成的,也有可能有的系统由于配置的关系,造成JRE Caching并不工作从而导致性能问题。
Citrix系统上面曾经有个这样的事例。这个系统上,每个用户都有唯一但是动态的"User"文件夹,每个session的缓存有可能不是存放在一起的。解决方法就是将缓存设定到同一个地址,这样在不同session直接就不存在缓存的问题。
下面的Wiki有关于JER Caching的详细配置及检测方法。
WIKI -Tips for Fine Tuning Performance for the Webi Applet
1.5 - 确保您的JER没有Security Change相关的问题发生
Java Security Update造成了非常多的关于Java Applet Interface的问题。下面是大家比较常见的一些问题:
WIKI - Web Intelligence and Oracle Java Runtime Engine Known Issues
上面的文章安装XI3.1和BI4.x分成不同章节进行了说明。下面这2个是BI4.0和BI4.1的具体章节。
这些问题都不是技术上的性能问题,但这些问题的存在会使您的终端用户在产品使用过程中遇到性能过慢等问题。
SAP一般在每几个月提供Patches/Support Packs等更新,一旦Oracle的Security机制发生更新,由于相对Oracle的更新BI的更新会稍微有些延迟,这就会导致您使用过程中出现由于oracle security 机制变更引起的问题。所以当您升级JRE版本的时候,请考虑以上因素再决定是否升级。
1.6 - 选择适合您的客户端 - Webi Rich Client vs HTML vs Applet Interfaces
每个客户端类型都有自己的特点及优点。在功能,性能以及简易型之间找到平衡是选择适合您的客户端的唯一标准。
WebI用户指南的章节1.4解释了各种客户端的区别,详读会有助于您的选择。使用哪种客户端并没有硬性规定,有的用户也许喜欢用HTML
interface查看报表,但是用Rich Client Interface来新建和编辑报表。
Help portal里面Web Intelligence相关文档的链接:
PORTAL - SAP BusinessObjects Web Intelligence 4.1 – SAP Help Portal Page
下面是BI4.1 SP6的文档链接:
GUIDE - BI 4.1 SP06 Web Intelligence User Guide - Direct Link
一般情况下,我们会做如下推荐:
Webi HTML Interface
适合主要查看已经做好的报表,或者只做少许更改的用户。
HTML interface在内部连接的是64位Backend server,但是比Applet Interface少些功能。
Webi Applet Interface
适合报表设计者,或者需要对报表进行数据分析的用户。
Applet Interface也是内部连接的是64位Backend server,并且通常能够处理大数据量或者计算量的操作,他依靠Backend server进行大压力操作。但是这是基于Web Application,所以在长时间操作,或是刷新大数据时会经常发生timeout.
Webi Rich Client Interface
拥有基本上所有的Applet Interface的功能,并且有自己的附加功能。推荐高级版设计者使用,以便在对大型文档操作时获得更稳定的设计环境。
可连接本地数据源比如Excel & Access,同样可以使用3层模式来连接Backend Server以获得更高的数据处理能力。
第2章 –实施最佳方案.
当说到实施最佳方案,我们通常是指在业务中优化Web Intelligence报表在实际业务中的使用流程及方法。本章节将为你介绍一些较为常用的业务优化方案..
2.1 –通过报表计划来节省时间和资源
这看起来很容易,但是实际上无数的support incident都是可以用合理利用计划和实时参照来规避的。.
您可以以5分钟为分界点,如果一个报表需要5分钟以上的时间刷新才能得到结果,那么建议用计划。计划报表可以将进程交给后台服务器处理从而将您从屏幕前漫长的等待中解脱出来。
计划报表的好处
研究表明在当今世界,终端用户甚至都不愿意用5秒多来等待视频加载,比如你在YouTube上点了播放按钮,你会愿意花5秒中等待视频加载吗?我想大部分人会直接放弃或是反复刷新。对于WebApplication用户来说也是一样的,如果一张报表用了一两分钟都打不开,用户就会选择关闭报表重试,或者干脆放弃。这样做的风险就是不断增加的请求加大了服务器的工作量。这有个典型的例子:
在上述的例子中,我们看到了下列不好的结果:
通过合理的利用流程安排和计划,上述的问题都是可以避免的。下面为大家介绍一下如何合理的优化计划:.
更多计划 和发布相关内容, 请参照下属链接:
文档 - BI 4.1 SP6BI 启动板用户指南 – 第七章–计划对象
文档 - BI 4.1 SP6 BI启动版用户指南 – 第十章–关于发布
2.2 –使用CMC中计划时的重试功能
尽管这不是一个真正的性能改善技巧,但是我们发现很多人都忽略了通过CMC执行报表计划时的重试选项。该功能允许设置当计划失败时间隔多久执行多少次的重试操作。.
下面是BI 4.1中该选项的截图:.
这个选项可以帮你节省计划失败后重新手动计划的时间。有些偶然的计划失败往往是由于服务器资源的不足等原因造成的,通过这种自动重试就可以是你在一台负荷大的服务器上避免许多类似的临时失败。
.
该选线既可以在默认设置/重复发生中设置也可以在计划/重复发生中设置。不同点在于前者可以适用于多有的计划工作,而后者作用于个别的计划工作。.
注意: 该选项只在CMC上进行计划时存在, BI Launchpad上目前还没有该功
2.3 –通过限制功能来减少环境中的计划实例数
再介绍个小功能叫做限制,同样可以帮助改善系统性能。实例限制可以设置在文件夹或具体对象上面。.
基本概念就是通过该功能来限制文件夹和对象保有的实例数,一旦超过这个限制,CMS会自动清理久实例来减少CMS DB和File
Store 磁盘中的数据,释放一定资源。.
下面是CMC 帮助文档中关于如何激活设定限制的介绍:.
设置限制可以允许自动删除BI Platform上的报表实例, 如果限制指定在文件夹上则作用于文件夹中的所有对象。
对于文件夹,您可以设定:
.
在CMC上激活限制功能的方法
下面是该功能的设定截图:
2.4 –调整平台搜索
您是否遇到过在没有任何用户操作下系统资源被占用的情况?如果有那很有可能是因为平台搜索.
什么是平台搜索?.
平台搜索功能使您可以在BI Platform存储中搜索需要的内容。它可以根据内容的关联性对搜索的结果进行分组和排序。.无疑这是一个很好的功能,我们只是需要在调整系统性能的时候对其加以考虑和调整。.
这面的文档介绍了这个功能以及如何配置:.
文档- BI平台管理员指南(BI 4.1 SP6) – 第二十二章- 平台搜索..
当BI4.0发布后,技术支持看到很多用户在迁移到4.0后遇到了很多的系统性能,资源消耗问题。.经过大量的研究,我们发现大多数的事例中问题都是由于新系统中对添加对象的索引导致的。那它是如何影响性能的呢?
平台查询程序会检测是否又新的内容需要被索引化和目录化。这就意味着任何一个新对象 (Webi Doc, Universe,Crystal Report等) 都需要进行分析,目录化,索引化。而完成后那个这些工作需要APS 上的搜索服务,当添加的报表存在很多的数据,对象,关键字时就会给系统带来很大负荷.如果您发现这占用了大量的系统资源时,可以用计划选项控制检索执行的时间。避开业务高峰时段应该可以帮助您改善性能。
相关信息您可以参照管理者指南文档的22章内容。简而言之,除非您有无穷无尽的资源否则一定要确保平台查询在您的监控范围内。
更多信息:
KBA - 1640934- How to safely use Platform Search Service in BI 4.0 without overloading the server?
BLOG - What is the optimal configuration for Platform Search in BI 4.x? - By Simone Caneparo
第3章 –报表设计最佳方案
本章节将为大家介绍一些通过报表设计提高报表性能的技巧,这些内容不单适用于新建的报表,对既存的报表也是可以少做改动进行应用的。.
强烈推荐这篇由william.marcy