原文地址（英语）：http://scn.sap.com/community/businessobjects-web-intelligence/blog/2014/12/18/revisit-the-sizing-for...
原作者: ted.ueda 现就职于SAP
2015好！希望您有一个满意的2014。这里，我想提醒您关注一下
重新规划部署BI4.x Web Intelligence Processing Servers
如果在过去的8个月您已经做完了以上的任务，那非常好。但是也请您在2015年日历上找一天重新做下这件事情。如果去年您没有做，我强烈推荐您在2015Q1练习一下。
我从BI4.0 Ramp-up阶段就开始支持Web Intelligence，到4.0在2011年9月16日正式发布，再到BI4.1发布。已经过去4年了，在这4年里，有3个非常重要的考量会影响到BI4.x WebI系统是否能平稳运行，(1)是sizing (2)是sizing (3)还是sizing。
如果您对BI系统构架做了不适当的sizing，那么您会遇到系统性能，稳定性，可用性的问题，如果现在没有相关问题，在您以后系统使用中也会发生。也许您会需要花很多时间在和技术支持部门的交流上，不过技术支持会首先询问您“上次什么时间做的sizing？”
如果回答是2014年2月以前，那么我们会推荐您文章Business Intelligence Sizing and Deployment，BI4 sizing guide，2014年2月更新版。在这个版本中，关于Web Intelligence的推荐配置有了更改。
规则1：参照最新的sizing guide做sizing
当您打开Sizing这篇网页时，我建议您选上"Follow"按钮，这样您就可以在网页有更新时随时得到最新消息。或者去https://service.sap.com/sizing页面，找到BI 4 Sizing Guide，点击"Subscribe"。
在最新更新中，对Web Intelligence services的推荐配置方面有更改，所以我强烈推荐您详读整篇文章，以确认您的BI4.1系统确实按照推荐的方式配置。
我和Platform Product Owner, Sada进行过讨论，他估计在BI4.2之前Sizing guide不会更改。但是上面说的可不算数，在您做sizing之前，一定要下载最新版本的Guide。
规则2：不能使用XI3.1的sizing guide或best practices来做BI4.1的sizing
曾经有一位客户抱怨他们的BI4.0系统构架的Sizing文档其中引用了XI3.1的文档。他们的系统使用了XI3.1同样的sizing构架。这当然不会好用，他们的系统发生了很多问题，但是在他们重新进行sizing之后，这些问题就消失了。
XI 3.1和BI 4.1是完全不同的东西，用XI3.1的构架来研究BI4.1就好比让马拉雪橇。不论这个东西有多么强大他们都不可能变成另一方。
这两个版本最主要的不同：
- BI 4.1 WebIPS是64位程序。XI3.1是32位程序，即使安装在64位机器上。
- .BI 4.1 WebIPS的query和chart生成的服务都分布在了不同的service。XI3.1是进程中处理。
因为以上不同，XI3.1的sizing best practices在BI4.1中是不合适的，甚至是有害的。我们来看下XI3.1的best practices以便与BI4.1做下对比：
XI3.1 - 一个CPU可以配置一个WebIPS
BI4.1 - 一个机器可以配置一个WebIPS
在XI3.1时代，CPU数量和WebIPS数量一致其实没什么必须的理由-因为WebIPS线程模式在多个CPU core中可以平行出来报表的请求。每个线程可以出来一个文档需求，但是不同的线程可以在不同的CPU Core中进行。WebIPS不会强制绑定CPU Core。
XI3.1是32位系统，所以一个能够使用的内存资源会限制一个WebIPS能够出来的job数量。所以那个时候，合理内存使用是XI3.1的sizing WebI的重要问题。随着使用的增加，会对系统处理能力增加提出更多要求。由于内存资源限制，最直接的方法就是增加WebIPS的数量。一个CPU可以配置一个WebIPS其实是增加机器数量的重要标准及规则。
但是BI4.1的WebIPS是64位程序，内存方面有很大提升。如果可以的话，我会推荐客户去更改BI 4.x WebIPS 的内存设置。
在Sizing Guide中，BI4.1的WebIPS是被IO限制的。你需要确保WebIPS能够得到的IO带宽，特别是虚拟机环境，只能是每台机器一个WebIPS。
曾经在BI4.0早期有过不同机器直接failover的问题（Document Recovery Service的相关问题）。当时我推荐书一台机器2个WebIPS（同一台机器两个WebIPS直接WebI session的failover不会使用Document Recovery Service）。但是那都是过去的事情了。
XI 3.1 – 启用内存分析
BI 4.1 - 不要启用内存分析
(2015-01-16更新)
我把这条加上因为这条建议不是经常被人们提起，但是我从一位WebI开发出得到消息，这条现在是推荐关注的。
BI 4.1 - 不要启用 Memory Analysis。现在默认状况下他是启用的（之后的版本可能会更改），但是他只是XI3.1时代的延续，对于现在来说不需要，甚至会因其发生问题。
在XI3.1时代，需要作出最大的努力就是珍惜使用32位内存空间。启用内存分析，在超过“内存上限阈值”时，会阻止WebIPS新进来的任何处理任务，而并不是存储报表。这个功能的最初目的是让用户在WebIPS内存枯竭的时候有个机会存储未保存的作业。并希望在达到“内存最大阈值”之前，能够阻止新的任务以使WebIPS能够在crash之前重新恢复功能。
BI 4.1 WebIPS是64位程序而且已经进行过改进，在内存不足之前就已经能够适当处理这种情况。“启用内存分析”就相当于无病吃药了。实际上，一直启用它有可能会造成系统不稳定-这里有客户曾经的事例。
在您下次计划停止BI Platform的时候，请登录CMC –>服务器–>服务器列表，取消所有WebIPS的“启用内存分析”。
XI 3.1 - “最大连接数”设为50，之后根据需要少量增加
BI 4.1 - “最大连接数”设为200，之后根据需要少量增加
“最大连接数”通常是由系统中活跃用户的数量决定的。如果您推算系统中会一直有200名活跃用户，可以将“最大连接数”设为200。但是会有的问题，以为WebIPS会将连接一直打开，知道Idle timeout。
所以即使您最多有200名活跃用户，还是有可能会出现200个以上open connections。所以会建议您根据需要少量增大这个参数。
对比旧的Sizing guide，经过多次测试，BI4.1中“最大连接数”设为200是最佳设置，BI4.1的WebIPS有更大的能够，足够可以处理50以上open connections。
如果您的系统有超过200名活跃用户，那么就需要增加一台机器，多部署一台WebIPS是明智选择。
XI 3.1 – 所有WebIPS的“Output Cache Directory”设置为同一个网络共享地址
BI 4.1 - WebIPS的“Output Cache Directory”设置为本地磁盘，而非网络共享地址
WebIPS初次打开某个WebI报表的时候，必须解压这个.wid文件，并内部生成相应的内容并解析。他会缓存这个生成的内容到磁盘上，在随后的应用中会使用他们。这些动作-打开/解压/解析需要经过很多处理。这样设计的好处就是下次再用这个WebI文档，过程就是先在缓存中查看是否已经有打开过的相应文档。如果有，就使用缓存的内容，不必在打开/解压/解析这个.wid。
现在，使用同一个Output Cache Directory的WebIPS可以共享其中存储的缓存内容。
这极大提高了打开WebI文档的速度，不同的WebIPS可以使用缓存中的数据来打开同一个报表，不论这个“打开”的要求是发给哪个WebIPS的。
在XI3.1，系统中经常会部署很多个WebIPS。一个CPU Core一个WebIPS，每50个活跃用户一个WebIPS。看到有16个WebIPS集群已经不是稀奇事。如果没有缓存共享，那么很有可能打开一个这个WebIPS没有打开过的WebI报表会极大影响性能。
但是在BI4.1里面，不需要那么多WebIPS，因为推荐的是一台机器一个WebIPS，每200个活跃用户一个WebIPS。所以XI3.1需要8个的时候，BI4.1只需要2个。缓存丢失的几率很小。另外，BI4.1的限制是在IO上，如果缓存是放在网络共享地址，那么系统性能将会被极大的限制。
因此，BI4.1建议WebIPS的“Output Cache Directory”设置为本地磁盘，而非网络共享地址。
不推荐使用网络共享地址来作为Cache Directory是有以下几点考量。
曾经有过网络共享地址来作为Cache Directory时，无法进行磁盘清理，而磁盘会因此被占满(SAP KBase 2050700)。网络连接问题会导致WebIPS停止响应(SAP KBase 1757824)。网络问题造成无法读取缓存造成WebIPS间断性shut down(SAP KBase 2057341) - 我将网络地址改为本地磁盘解决了问题。
总之，BI4.1建议WebIPS的“Output Cache Directory”设置为本地磁盘。
如果你有一个非常复杂并且庞大的，会让WebIPS处理很长时间来解析的WebI报表，你可以新建一个服务器组其中包含一个特定的WebIPS。指定那个WebI报表用这个专用的WebIPS来处理，这样就不会调用其他的WebIPS，而且缓存会保存。
规则3：经常重新进行sizing。并谨记sizing guide是起始点-是一份说明，不是规则
您对BI系统的使用不会是一成不变的-会创建新的文档，报表数据量会以倍数增长，查看报表的用户会增加等等。这是件好事，因为这说明您的BI系统是个不错的系统所以人们会不断增加对他的需求。但是这也就需要您不断的重新规划，确定执行的文档的个数与大小，监时与观察WebI Processing Server的负载。
至少每年做一次Resize。
BI 4 Sizing Guide是起始点。编写这个Guide的工程师有着非常丰富的测试经验并且能够做出合理的推荐。但是在他们的测试中，比如“活动的用户”的活跃程度，“大”的文档的大小程度都有别于您的实际的配置。只有您自己明白您的系统的情况，Sizing等同于tuning。您有可能一年只对您的系统做一次sizing，但是对于您的系统的健康度的观察却是要时时进行的。
规则4：分割并size Adaptive Processing Server
这是非常重要的一条规则，同样也是一个topic。下篇blog我会介绍。
这样说吧，BI4.1中初始安装的单独的Adaptive Processing Server是非常不适当的，还不如一个POC系统。如果没有进行合理分割并size (SAP KBase 1694041)，您的系统会或多或少出问题。
总结
Sizing是保证SAP BusinessObjects BI Platform 4.1的Web Intelligence 稳定和高效运行的最重要的考量点。在本篇blog中，我简要介绍了Web Intelligence Processing Server的sizing。在下一篇中，我会介绍Adaptive Processing Server的sizing。
