简短的版本：

以下是一个简短的咆哮，涵盖了最近的挑战，解决关于商业智能报告绩效（有点情绪化）主题的担忧/投诉。我目前正在努力收集同行的意见和经验，如果大家能对自己在这一领域的经验发表意见，我将不胜感激。

我的目标是（最终）为我们的BI用户社区提供有证据的目标和阈值。我们希望比较我们的目标（详见下文），了解同行组织正在做什么，看看这些目标是现实的还是典型的。

如果您有时间，请参加以下调查：行业对BI报告绩效的看法，目标和阈值

长版本-背景：

在最近的全球转型计划中，创建了一个全球BI实例（BW7.3+BWA和BOE 4.0（后来迁移到4.1））。由于BI基于新的单实例ECC，因此部分报告要求是全新的，通常会取代手动数据提取和整理过程。

为了满足全球受众的要求，同时保持报告信息和布局的灵活性，以下是典型的：

部署了多种技术来满足需求：

Crystal和Analysis报表使用BW查询作为其语义层，并发布到（或从）BusinessObjects Enterprise platform（SAP BI4）中调用。BI仪表板和Web模板发布到SAP BW中，云教云，并通过NW Java调用。

由于报告取代了许多手动过程，因此最初决定不需要应用性能目标，因为需要几天甚至几周时间的手动过程将被运行时间为几分钟的报告所取代。当然，一旦报告真的在用户手中，消息就丢失了，性能问题就出现了。为提供谈话的起点和后续补救行动计划，通信云，引入了绩效阈值。见下图。

在设计和构建报告时，自助建站服务，这些阈值不到位，一站式建站，因此许多报告，尤其是那些将多个报告要求聚合到一个报告中的报告，超出了这些阈值。至少我们现在有了一个基线来处理"我们的商业智能报告太慢了！"抱怨

BI性能的话题，特别是用户的端到端报告运行时体验，充其量通常是一个主观的、往往是情绪化的主题。近几个月来，区分主观和客观，确定监控/测试/故障排除的标准/方法以及提出性能改进建议一直是我工作日的一大部分。还有晚上。我们生活在这样一个时代，人们期望网页能在几秒钟内对他们的信息需求做出反应，所以一份需要几分钟才能运行的报告被认为是慢的。对于那些在BI工作的人来说，有些人可能会同意我的观点，即只有那些运行超过24小时并且在源代码被删除和重新加载之前有失败风险的报告才会慢到成为问题！那么，什么是"慢"，我们如何使它成为可量化和可测量的东西？

我们的答案是部署Solution Manager的最终用户体验监控。这最终让我们就性能进行了基于事实的对话。如果用户说报表"慢"，我们可以评估它是否以预期的速度运行。如果是这样的话，我们可以推断出用户只是判断报告的运行速度比他希望的慢（我们称之为"谷歌效应"）。如果该报告的运行速度比该报告的常规基准慢，那么我们可以看到是否存在持久性问题，或者它是否是一个孤立的峰值。无论哪种方式，我们都可以根据事实来管理用户的期望。就管理绩效预期而言，这本身就是我们的一个重要里程碑。

一件很快变得明显的事情是，并非所有地点都是平等的。一份在欧洲"如预期"运行的报告在某些低延迟地理区域的运行速度可能会慢一倍。Solution Manager的最终用户体验监视在这里也很有用，因为我们可以查看报表运行时的历史记录并将报表与自身进行比较，也可以将一个位置的报表运行时与另一个位置的同一报表进行比较。这并不能解决任何问题，但允许围绕性能进行基于事实的对话，而不是通常的情绪化对话。相信我，这是问题的很大一部分。

基础设施是一个恶化的因素

显然，作为一个托管全球实例的大型企业组织，BI解决方案被包装在多个IT集成层（防火墙、身份访问管理、负载平衡器等）中。很明显，无论我们对报表和查询进行了多么良好的微调，都有其他方面严重影响了性能。我们确定了所有的"支柱"，以及支柱中的"斑点"，并成立了一个工作组，重点是确定和解决任何瓶颈。有些人比其他人容易。

事实上起了作用…不，真的！

一些捷径（如果有人感兴趣，我可以在评论中详述）是防火墙上的更改以调整超时、增加BW中对话进程的数量、应用各种各样的SAP注释、更改门户以及对许多报表服务的BI-platorm设置进行一些调整。目前正在考虑一些更棘手的问题，如对虚拟化层进行重大更改或升级到BI4.1 Service Pack 6。

最终结果是，即使做出了所有这些努力，我们公司的大部分"核心"报告仍然超出了阈值。虽然我们继续做出所有积极的改变，我们可以，这很可能是永远递减的回报。这就是我渴望从同龄人那里得到反馈的地方。正如我在这篇文章的开头提到的，我们正在努力确定我们的方法（或者更确切地说，我们的目标和门槛）是否与其他组织一致。