在与内部同事和客户进行了一些讨论之后，我发现很多人都面临一些应用程序的性能问题。我试图收集您在统计文件中找到的信息，以及您可以采取的可能措施，以通过更改脚本来提高性能。

基础知识

如果您已经知道如何在design studio中执行pfofiling，您可以继续此博客。

如果您不知道，请参阅Design Studio提示和技巧：测量性能（Martin）或使用示例测量Design Studio应用程序的性能（Muralikrishnan）。

执行。

无论您想测量什么，请始终为自己制作一个包含以下内容的包：

这将帮助您分析内容和脚本，并查看对运行时的影响。

开始调查。

我们从"bi"开始_统计.txt"文件。只需打开它。

大模块–首先请求

在文件中，您可以看到以下大模块：

这是主结构。那些积木是什么意思？

（1）流程页面命令设置\模板

这是设置应用程序所需的所有对象的部分。这部分的表现受到

你能做什么的影响？

（2）呈现前处理命令

这部分是onStartup脚本的完整执行。这里的性能取决于onStartup事件中编码的内容/脚本。

您能做什么？

（3）进程呈现

这部分是应用程序的呈现。您将在这里看到所有组件和所有数据请求所需的时间。这部分应该已经很好的优化了，结果集只有在真正有人需要的时候才需要它。

你能做什么（不多）？

大数据块–更多请求

您是否在第一次执行中看到多个请求？

如果是，则表示您正在使用onBackgroundProcessing事件。在这种情况下，检查那里发生了什么-也许在启动阶段已经不需要某些东西了，但是首先当所使用的东西进入可视化时？

你能做什么？

一些搜索提示

现在，一些帮助的"搜索分析"的网站统计.txt文件。只需搜索给定的内容，看看它是否适合你。如果需要事件计数，还可以使用CSV文件并按列进行筛选（文本包含..）。

Process page command CREATE_DATA_PROVIDER（12608）

这是创建数据源对象，每个数据源一次。

Process page command CREATE_ITEM（12608）

这是创建组件，每个组件一次。

这是组件创建的纯过程，实际上没有什么可以影响时间。如果服务器有更好的CPU，什么是物联网工程，这个时间是0毫秒。

获取连接

这是打开BW/HANA/Universe连接所需的时间。如果你看到这里很多秒，你的网络有问题。一般来说，对于同一个系统，您应该看到第一次出现时花费了一些时间，然后应该是0毫秒。

RFC BICS\ U PROV\ U OPEN（10000）

每个数据源都需要打开（例如BW）。此操作所需的时间取决于查询定义，只有您可以更改查询。

RFC BICS\u PROV\u VAR\u GET\u VARIABLES

这是请求变量，在大多数情况下不应占用太多。

RFC BICS\u PROV\u SUBMIT\u VARIABLES

SUBMIT of The VARIABLES。这是一个有趣的一个，检查有多少你看到-理想情况下只有一个。如果你看到一些"复杂的结构"，我的意思是提交，然后在一个导航步骤中再提交一些其他的东西，这在很多情况下是"糟糕的脚本"的表现。这可能是由脚本中的疯狂序列造成的——设置变量，然后请求一些东西（比如getData），然后再次设置变量。getData ask隐式提交变量。

RFC BICS\u PROV\u GET\u MEMBERS

这些调用"很重"，从BW系统请求的成员可能需要一段时间。也许你不需要他们在启动，也许更好地使它在后台处理？这是由脚本调用"getMembers（）"引起的。您也可以尝试在一个方法中绑定这样的调用，使用变量来避免多次调用（因为不是所有调用都能被BICS数据层缓存）

呈现Ui项

对于那些小调用，您应该不会看到任何长时间的花费。大多数应该是0毫秒，大数据数据处理，有些可以更高。如果一个是超高的，就有可疑的东西。

进程页命令设置\u项\u参数

请记住，组件的每个.SET（）方法都需要更改组件状态。这就意味着，你应该避免用大众化的方式来称呼设定者。例如，如果要隐藏10个组件，请将它们绑定到一个面板（面板很便宜），然后更改面板的可见性，而不是每个组件的可见性。您将此操作的服务器内部处理减少10.

获取结果集

我认为这是此博客的最终事件，在这里您只能改进后端以使其更快。它是查询结果集的请求。更小（更好的过滤器）的性能更好。

更多的事件…

当我得到更多的例子，我会尝试在这里添加更多的内容。

其他链接：

设计工作室性能最佳实践（马丁）

设计工作室1.5-性能发布（马丁）

非常好的见解卡罗尔。

Rgds，

Murali

Karol解释得很好，谢谢。