使用对性能有负面影响的用例
本部分列示对 Optimize 的性能有负面影响的不同用例。
具有使用要约版本的规则的智能要约列表
如果您使用智能要约列表并且此列表具有使用要约版本的规则,那么在占用 IO 最多的数据设置部分中还用到其他查询。如果列表中的要约数目较大,并且每个要约的属性数目也较大,那么可能需要较长的时间来运行这些查询。
每个客户样本的迭代的高最大值
使用 Optimize|AlgorithmTuning|MaxIterationsPerCustomerSample 属性可以配置要对每个客户样本使用的最大迭代数。检查会话级的高级设置和配置属性。
客户样本可能不会达到此限制,具体取决于规则和数据。高值将确保最高级的结果最优性,但是往往使用更大的迭代数对最优性所带来的改进尚不足以证明牺牲性能是值得的。通常,五次迭代将获得可接受程度的最优性,并且以往很少出现需要大量迭代的情况。
要分析客户样本的迭代行为,请在 Optimize 日志中搜索字符串迭代:。此日志条目后接数字,指示它是哪个迭代。每个区块以迭代 1 开始,然后算出总数。如果您获取日志中每个迭代数的计数,并使用此结果构建柱状图,那么它将有助于您查看目前的工作情况。
较高的无法处理的客户数
另一个主要性能因素是无法处理的客户数。如果 Optimize|AlgorithmTuning|MaxAlternativesPerCustomerEvaluated 属性的值是一个较大的数(大约超过 100),那么当无法处理某客户时,时间牺牲会较高。
当您具有许多无法处理的客户时,请查找规则或数据中的逻辑错误。但是,获取某些针对每个客户的解决方案所需的时间可能会较长(特别是当每个客户有大量建议交易时)。如果是这样,那么可能最好将 MaxAlternativesPerCustomerEvaluated 参数的值降低,将接受更多无法处理的客户作为改进性能的权宜之计。
Optimize V7.5.3 及更高版本中,有更多详细的日志记录以显示对每个客户样本评估的备用解决方案的最小数、最大数和平均数。
解析程序子例程调用
如果使用每个客户规则的特定组合,那么在某些情况中可能会出现较大的性能牺牲。当至少存在一个每个客户的最小/最大交易数的规则且最小约束不为零,并与一个或多个数据包规则合并使用时,可能出现此情况。
*
除有这两个规则外,它们的范围必须重叠以便两者均应用到相同的建议交易。此外,分数必须是这样,数据包规则的首选解决方案将使“最小/最大”规则降至其最小值以下。如果满足以下所有条件,那么核心算法无法以高效的方式找到最佳结果,并且必须使用较慢的解析程序引擎调用。 当您在服务器日志中见到消息解析程序子例程参数:时,您会知道正出现此情况。
如果您从使用“A 从不与 B 一起使用”规则中发现性能问题,那么改进性能的最佳方式是升级至 Optimize V7.5.3 或更高版本。
分数相同的许多情况
如果在许多情况下分数相同,那么在 LRE 中进行决策有时可能会变得低效。如果在服务器日志中见到以下字符串,那么您就会知道处于此情况:已生成其他备用解决方案:
要避免出现此情况,请尝试向建议的交易分配更多不同的分数。