Graham，

您的问题似乎与HCM传输无关，或者至少与它无关。 您试图同时查看许多流程，但我认为这不是解决案件的正确方法。 您应该开始逐步解决问题。

所以我的建议是s：

仅从HCM传输开始-这意味着您应该停止所有其他过程，分配或任何其他操作。 只需创建一些从HCM到Main ID Store的用户，而无需任何其他操作，然后检查时间即可。

如果这里有问题，则意味着您可能有网络问题，或者问题出在数据库中。 但是，如果不解决此问题，请不要继续下一步。

下一步-如果您已解决了第一步中的所有问题，请尝试仅在一个ABAP系统中分配用户，然后再次检查速度。 如果您遇到问题-再次可能是网络问题，ABAP系统可能超载，可能是数据库问题或可能是IDM配置问题（即检查访问配置的分组设置）。 同样，在这里解决所有问题之前，请不要进行下一步。

下一步-为多个ABAP系统提供服务-如果上一步中的所有问题都已解决，则最有可能在这里讨论IDM配置问题。 要么在调度程序中，要么在IDM中它本身。 您应该记住，IDM标准配置在队列中而不是并行地对相同类型的后端系统进行配置。 这意味着IDM试图在执行一个系统之前执行所有任务。 可能这就是它对您如此缓慢起作用的原因之一。 当然，有一种方法可以使这些过程并行运行，但这有点棘手，在某些情况下，它可能导致无法预测的结果，因此应谨慎进行。

最后但并非最不重要的一点是，如果您没有很多经验，也不要与调度员打得太过分，因为结果可能会比当前情况差。

此致

Ivan

您好，

我想与我分享有关性能主题的一些经验...在上一个IDM GoLive期间，我们遇到了类似的问题。 我们必须从HCM向IDM转移大约12.000名人员，按照定义的规则进行处理，在SAP后端（40个存储库）中分发信息，并在HCM中保持信息类型。
第一次运行在之后取消 我们发现了严重的性能问题。 LDAP传输本身不是什么大问题； 40分钟后完成。 但是IDM的处理花费了很多时间，每个人员人数大约需要45秒。 我们有一个最大时间窗口。 4小时。.

我们为优化所做的工作：
-优化了数据库设置，参数更改，增加了流程，按计划创建表和索引统计信息
-设置了一个IDM调度程序来处理HCM处理， 另一个供后端使用的资源-限制每个流程步骤和调度程序级别的日志记录； 它设置为" Info"，这会创建许多我们不需要的日志，因此我们增加了它以仅显示警告-因此，我们还对uInfo/uWarning函数的自定义脚本进行了交叉检查。
"最大并发rt引擎 调度程序的""和" rt引擎的最大循环"参数也影响了我们的整体性能，因为IDM创建了许多Java进程，这些进程几乎"杀死"了系统（和数据库）。 在IDM方面，有太多的过程正在消耗CPU和内存，因此服务器已完全耗尽。 另一方面，DB无法再处理请求。 现在，我们发现并发引擎（以及数据库进程）具有很高的价值。
-我们还检查了分配给SYSTEM-privilege的属性，默认情况下，分配了许多不必要的属性，结果IDM触发了许多无用的配置任务。 我猜属性的数量减少到15个。
-处理人员编号的IDM流程逻辑进行了一些更改（验证，写入SAP主数据库，后处理等）。

< p>
这样做，我们可以将agg运行时间优化为每个人员人数2-5秒。

但是，处理数据的最佳方法是更改​​HCM流程。 我们使用RPLDAP_EXTRACT_IDM中的delta函数。 通过实施HR_LDAP_EXTRACT_PA，人力资源部门进行一些更改后，相关人员编号便会标记为通过表HRLDAP_PERNR转移到IDM。 我们在HCM中运行另一个Z *小报告，该报告还检查相关人员编号。 所有这些都存储在表HRLDAP_PERNR中。 每小时运行一次IDM增量抽取； 所以我们有最大 每次运行要处理的人员数量为10-20，这对性能没有任何影响。 此外，更改和用户信息将在很短的时间内提供。

Richard

嗨，Richard

尽管我的每条记录大约需要10到12秒的时间，但在遇到类似情况时，您是否能够提供有关所做更改的更多详细信息。 我认为对于IDM系统来说，这仍然非常慢。

我们已经设法将负载从每条记录3分钟以上降低到每条记录12秒以下。

设置10个ABAP系统需要8秒，而配置AD则需要3秒。

大多数是DBA所做更改的结果。 我们正在使用ASE DB，发现我们有一个8核系统，但调度程序仅使用1核。 其他人正在处理其他任务。 一旦我们切换到8个核心，您就可以想象得到的增加。 这样一来，我们可以忍受的总寿命不到30秒，但是在测试负载时，Basis和DBA团队与我们做了很多工作，就像我说的那样，设法将其降至12秒以下。 如果有人对这些详细信息感兴趣，可以查看是否可以发布。

您好，Graham，您能给我更多有关性能设置的详细信息吗？ 我们有同样的问题。

预先感谢