我的分析过程造成差异的可能因素有哪些最终答案吸取的教训

昨天我花了几乎一整天的时间来解决一个crmfiori应用程序"mylead"中的超时问题。最后根本原因让我不知道是发射还是哭泣。我和大家分享这个故事，如果你遇到类似的问题，你不需要像我昨天那样花太多时间去调试，

在CRM"我的潜在客户"应用程序中，最终用户可以同时在一个潜在客户中插入多个产品，

用户可以点击"+"按钮打开产品价值帮助，然后选择他们需要添加到lead中的产品。

问题是，当测试同事使用测试用户（我们称为用户A）将产品插入lead时，他们会遇到下面的超时错误，国内大数据公司排名，当所选产品的数量超过15时。

令我惊讶的是，啥叫大数据，当我使用自己的用户（用户B）进行测试时，该问题无法复制，仅用了1秒钟就完成了插入，选择了20种产品。为什么？

1. 我和测试用户A一起调试了产品的插入，产品的导入是通过CRM功能模块CRM\订单\维护来完成的。该FM中的产品插入是通过内部环路完成的，这意味着每个产品都是单独插入的。对于总共20个产品插入，我跟踪执行时间，大约需要40秒才能完成，这绝对是不可接受的。我使用事务代码SAT跟踪测试用户A的单个产品插入，淘客返利系统，大约花了2秒钟。执行时间似乎随着要插入的产品数线性增加。另外，单次产品插入2秒是不可接受的–太慢！！

3. 不幸的是，通过SAT记录，我找不到执行的瓶颈。每个堆栈的完整执行都非常慢。但是当我用自己的用户进行调试时，每个堆栈都非常快。我假设两个用户正在测试不同的潜在客户交易类型。不同的事务类型可以注册不同的回调，因此在保存lead时，可以执行不同的程序。在我检查后，此元素被消除-两个用户正在处理完全相同的事务类型。

2。后端实现有一些类似

的代码，我做这个假设的原因是因为执行过程根据用户的不同而不同，所以在基于用户名的代码中一定有一些处理

我花了很多时间去看代码，答案是否定的

我觉得很沮丧，几乎放弃了。突然我想到了用户设置差异的可能性？？

宾果！测试用户通过用户参数CRM\u event\u trace开启了一阶框架事件跟踪

此跟踪功能代价昂贵，导致整个程序执行的开销。而且由于是在一阶架构中集中完成的，所以我在应用程序代码中找不到任何提示

所以这里有一些经验教训：

下次遇到类似的问题，不同用户的同一个应用程序的性能差别很大，云服务器怎么样，除了"导致差异的可能因素"一章中提到的两个检查点之外，还有最后一个但不是最不重要的检查点：检查两个用户之间是否有不同的用户设置（例如tcode SU01，软件企业条件，或您特定区域中的任何其他自定义设置）。