2.3 性能调节

性能调节是一个复杂的话题。 Identity Manager 用户应用程序依赖许多技术的大量交互过程。 因此，无法预测哪个单独的配置方案或用户交互方案可能导致性能降低。 尽管如此，部分子系统仍可采用能够增强性能的最佳做法。以下是对这些做法的说明。

2.3.1 日志记录

用户应用程序允许通过 Novell Audit 和开放源代码的 Apache log4j 框架进行日志记录。 默认情况下不通过 Novell Audit 记录日志， 但将启用通过 log4j 进行文件和控制台日志记录。

注：有关可以记录日志的事件类型，以及如何启用或禁用日志记录，可参见本指南下文中的部分 5.0, 设置日志记录和部分 12.0, 日志记录配置。

log4j 配置设置包含在 $IDMINSTALL/jboss/server/IDMProv/conf/ 下名为 log4j.xml 的文件中。 在该文件的底部，您将找到以下项：


<root>     <priority value="INFO" />     <appender-ref ref="CONSOLE" />     <appender-ref ref="FILE" /> </root>

为 root 赋值，以确保不具备显式指派级别的任何日志附加程序继承 root 的级别（在此例中为 INFO 级别）。 例如，默认情况下，未对 FILE 附加程序指派阈值级别，所以它采用了根的阈值级别。

根据 org.apache.log4j.Level 类中的定义，log4j 可能使用的日志级别包括 DEBUG（调试）、INFO（信息）、WARN（警告）、ERROR（错误）和 FATAL（致命）。 不注意正确使用这些设置将严重降低系统的性能。

一个好的经验是仅在调试特定问题时才使用 INFO 或 DEBUG 级别。

对于设置了级别阈值的根中的任何附加程序，只要不进行调试操作（如前所述），都应将其阈值设置为 ERROR、WARN 或 FATAL。

就高日志级别对性能的影响而言，log4j 中控制台和文件日志记录（涉及同步写入）的影响要大于讯息冗长的影响。 可以使用 AsyncAppender 类，但使用它不能保证更佳的性能。 有关这些问题（众所周知的 Apache log4j 问题，而非 Identity Manager 问题）的说明，请访问 http://logging.apache.org/log4j/docs/api-1.2.8/org/apache/log4j/performance/Logging.html。

用户应用程序日志配置文件（见上文）中的 INFO 默认级别可满足多种环境，但是在性能至上的场合，则需考虑将上面的 log4j.xml 项更改为：

<root> <priority value="ERROR"/> <appender-ref ref="FILE"/> </root>

也就是说，要去除 CONSOLE 并将日志级别设置为 ERROR。 对于经全面测试/调试的生产设置，无需以 INFO 级别记录日志，也无需将 CONSOLE 日志记录保留为启用状态。 关闭这些设置所带来性能收益会非常显著。

有关 log4j 的更多信息，请参考 http://logging.apache.org/log4j/docs 中提供的文档。

有关更多与 Identity Manager 一起使用 Novell Audit 的信息，请参考《Novell Identity Manager 管理指南》。

2.3.2 Identity Vault

LDAP 查询在高占用率目录服务器环境中可能会成为瓶颈。 为了保持处理大量对象时的高性能，Novell eDirectory（Identity Manager 中 Identity Vault 的基础）会频繁地记录请求信息，并将信息储存在索引中。 对其特性已编制索引的对象运行复杂查询时，查询返回速度大大加快。

eDirectory 自带了以下已编制索引的特性：

Aliased Object Name cn dc Equivalent to Me extensionInfo Given Name GUID ldapAttributeList ldapClassList Member NLS: Common Certificate Obituary Reference Revision Surname uniqueID uniqueID_SS

安装 Identity Manager 时，将使用新的对象类类型和属于用户应用程序的新特性扩展默认目录纲要。 默认情况下，特定于用户应用程序的特性不会编入索引。 为了实现更佳的性能，您会发现将其中一些特性（可能还有一些传统的 LDAP 特性）编入索引会非常有用，特别是在用户树枝包含 5,000 个以上的对象的情况下。

一般的想法是仅对已知需定期查询的特性编制索引。 （不同生产环境中也完全可能是不同的特性。） 确认哪种特性使用率更高的唯一方法是收集运行时谓词统计数字。 （但是，收集过程本身也会导致性能下降。）

《eDirectory 管理指南》中对收集谓词统计数字的过程进行了详细介绍。 该处也对索引进行更详细的介绍。 通常，需要进行以下操作：

  • 使用 Console One 打开感兴趣的特性的谓词统计数字集合
  • 使系统处于负载状态
  • 禁用统计数字集合，并分析结果
  • 为每种可能从索引中受益的特性创建索引

如果已知道要对哪种特性编制索引，则不必使用 Console One。 可以通过《eDirectory 维护》>《索引》在 iManager 中创建并管理索引。 例如，如果知道组织结构图中的用户将很可能基于 isManager 特性执行搜索，可以尝试对该特性编制索引，以查看性能是否得到增强。

注：最好的做法是至少为 manager 和 isManager 特性编制索引。

有关对特性编制索引和性能的深入讨论，请参见 Peter Kuo 和 Jim Henderson 编写的《Novell eDirectory 查错指南》中的《调节 eDirectory》章节（QUE Books，ISBN 0-7897-3146-0）。

也可参见主要的《eDirectory 管理指南》中的《维护 Novell eDirectory》章节（其中包括性能调节指导）。

2.3.3 JVM

分配到 Java 虚拟机的内存堆内存的数量会影响性能。 如果指定的最小或最大内存值过低或者过高（过高意味着超过了计算机的物理内存），页文件交换可能会过多。

通过在文本编辑器中编辑 [IDM]/jboss/bin/ 下的 run.conf 或 run.bat 文件（前者适用于 Linux，后者适用于 Windows），可以设置 JBoss 服务器的最大 JVM 大小。 将《-Xmx》从 128m 增加到 512m，或者更高。 可能需要一些试验来确定特定环境的最佳设置。

注：可以在 http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossASTuningSliming 中找到 JBoss 和 Tomcat 性能调节提示。

2.3.4 会话超时值

可以在 IDM.war 存档的 web.xml 文件中更改会话超时（在服务器引起会话超时的警告对话框出现之前，万维网浏览器中的页面处于无人值守状态的时间量）。 应该调节该值以使服务器与应用程序要运行的使用环境相匹配。 一般情况下，建议尽量减少会话超时。如果业务要求可以接受 5 分钟的会话超时，则与超时值为 10 分钟相比，服务器释放未使用的资源的速度可提高一倍。 这将使得万维网应用程序具有更高的性能和可伸缩性。

调整会话超时时，请考虑以下问题：

  • 如果短时间内有很多用户登录，则较长的会话超时可能导致 JBoss 服务器内存用尽。 对于任何打开会话过多的应用程序服务器都是如此。
  • 用户登录到用户应用程序时，将为该用户创建 LDAP 连接并与会话联结。因此，打开的会话越多，保持的 LDAP 连接数目就越多。 会话超时越长，保持的连接打开的时间越长。LDAP 服务器的打开连接过多（即使为空闲连接）可能会导致系统性能降低。
  • 如果服务器开始出现 OutOfMemoryErrors，并且已对服务器和使用环境的 JVM 内存堆和垃圾收集调节参数进行了最佳调节，那么应考虑缩短会话超时。

要调整会话超时值，需要打开 IDM.war 存档，在其中查找 web.xml 文件，并编辑文件的以下部分（特别是此处显示为 20（表示 20 分钟）的数字值，该值为默认值）：

<session-config>     <session-timeout>20</session-timeout> </session-config>

然后需要保存文件和存档，并重启动服务器。

注：最好由熟悉 Java 万维网应用程序开发和部署的人员进行万维网存档文件手动编辑。