Tom Alcott
IT 咨询专家, IBM Software Group, Worldwide Sales
2005 年 8 月 1 日

对有关 IBM® WebSphere® Application Server 的一些常见问题的明确（并不那么确定）的回答。

常见问题
既然您来到这里阅读这篇文章，我就得坦承我有点“挂羊头，买狗肉”之嫌。本文并不是讨论人们不敢问的有关 WebSphere Application Server 的问题（坦白地说，您不敢问的问题没有那么多），而是我想抓住这个机会对可能时常被问起的一些问题进行阐述。

我向 Douglas Adams 致歉，在涉及这些问题时，我宁愿回答“42”（译者注：在 Douglas Adams 所著《银河系漫游指南》中，42 是关于生命、宇宙以及所有一切的答案），或者是除“视情况而定”之外的几乎任何内容，但您即将明白，对这些问题最准确的回答通常是：视情况而定（应用程序、基础结构、性能或可伸缩性要求等）。不过，这表明我确实是在尽力向您提供一些指导，以帮助您确定符合您具体情况的最佳回答，此外，我还对一些常见问题进行了明确的回答。好了，我们开始吧。

问：运行应用程序所需 CPU 的最小数量和最大数量是多少？

答：从我作为 IBM 红皮书 WebSphere Scalability: WLM and Clustering Using WebSphere Application Server Advanced Edition 的合著小组成员到现在，已有 5 年了。在该书中，我撰写了一个标题为“How Many Clones”（克隆的数量）的讨论，其中，我试图解决运行我的应用程序需要多少应用服务器？这一问题。CPU 问题就是我现在经常遇到的这一类问题，实际上，这个问题也是采用视情况而定 的方式进行回答的典型问题之一，因此我们先了解一下它取决于哪些因素。

现代操作系统通常在进程调度方面表现得很出色，从而最大程度减少了上下文切换。上下文切换是在操作系统调度程序用另一个进程替换 CPU 上正在运行的一个进程时发生的，而且是各种因素作用的结果，例如作业（或进程）优先级、是否等待其他资源（如 I/O）、进程是否将用完所有分配给它的 CPU 周期（时间片）等。但是，在执行上下文切换时，虽然现代操作系统表现很“出色”，却并非“完美无缺”，因为进程在每次进行上下文切换时，它都将停止运行——这将导致吞吐量出现延迟（和性能下降）。如果我们确实不希望出现任何上下文切换，则系统中的 CPU 数要大于该系统中运行的进程数。而这完全不切合实际，因为在一个系统中安装这么多的 CPU，几乎没有任何组织能负担得起，而且也没有必要，因为大多数进程都不要求对 CPU 进行持续访问。因此，我们应该转而研究一些最重要的进程，这些进程在本文中即指系统中应用服务器运行时所使用的JVM。

起初，我们假定每个应用服务器 JVM 应该采用至少一个 CPU；这样就有可能最大程度减少发生上下文切换的次数——至少就将用完时间片这一因素而言是如此（如上所述，导致上下文切换还有其他因素）。但是除非您在运行所有服务器时占用了全部 CPU 资源，否则，在应用程序请求（该请求随即被转换为对操作系统资源的请求）到达应用服务器时，很可能存在可用的 CPU 周期。因此，运行的应用服务器数量有可能大于 CPU 数量。

不过，如果要获得可以在环境中运行的服务器的准确数量，则还得采用视情况而定 之类的方式进行回答。这是因为该数量实际上取决于负荷、应用程序、吞吐量和响应时间要求等，确定这个准确数量的唯一方法是在环境中运行测试。

在开发环境（其中负荷可能是每个应用服务器只有一个用户）中，您会期望每个 CPU 运行的应用服务器实例数量是生产环境中的应用服务器数量的数倍，这种想法很合理。尽管如此，也很难确定具体的应用服务器数量，虽然为所有应用服务器添加足够的内存也是个相当重要的因素。根据经验，所有 WebSphere Application Server JVM 进程加在一起的大小不应超过服务器上未使用物理内存的 80%。在计算该数字可以达到的最大数目时，您必须考虑的不仅有最大堆大小，而且还有除最大堆大小之外的 Java™ 字节码解释器的进程大小（这个大小在操作系统进程表中列出）。字节码解释器向进程表大约添加 65MB（除了最大堆大小 128MB 之外），并随最大堆大小的增加而增加。

在解决了 CPU 的最小数量后，您可能要问，最大 CPU 数量是多少？ 如果您了解到回答也是视情况而定，那不必感到惊讶。一个非常高效且经过精心编写的应用程序只通过一个应用服务器进程即可使用多个 CPU。事实上，WebSphere Performance Lab 在运行涉及 Trade 性能基准时，使用了 12 个 CPU（有时更多）。而期望大多数应用程序具有这种伸缩性可能是不合理的，但大多数经过精心编写的应用程序都应能通过应用服务器使用多个 CPU（实际上，只使用一个 CPU 通常表示存在应用程序瓶颈）。在任何情况下，我 5 年前执笔的 WebSphere Scalability 一书讲述的确定最佳克隆（或应用服务器实例）数的指导原则仍然适用：

而且如您所见，对此问题的最终回答还是视情况而定。

问：在将本地系统用作 Windows™ 上的安全注册表时，WebSphere Application Server 为何需要“Act as part of the operating system”权限？

答：这个问题的回答实际上是确定的，不过在此我还得使用视情况而定 进行回答。

在任何操作系统上，如果用户注册表保存在本地，WebSphere Application Server 就需要执行本地操作系统调用，用于对底层用户注册表进行认证。对于 Windows，必须有“Act as part of the operating system”权限才能执行特定于 Windows 的本地操作系统调用。（说一点题外话，要在 UNIX® 上使用本地调用，您必须以 root 用户身份运行 WebSphere Application Server，因为 root 是可以查询注册表来获得系统上所有用户 ID 的唯一用户 ID。）我认为，操作系统限制对密码检查 API 进行访问的原因是，如果不加限制，任何用户都可以使用任何用户级程序调用它们，而且有可能使用字典攻击来试图获取用户的密码。强制用户首先获得 root（或作为操作系统的一部分）访问权限来限制此类风险的发生。当然，这种方法不是完美的，但还是有一些帮助。别忘了，这不是“WebSphere 要求”，而只是底层操作系统的要求。

因为操作系统各有特点，所以一般建议将 LDAP 用作安全注册表。这样，在使用不同的操作系统进行部署、测试和生产时，就不必考虑操作系统之间的差异。使用 LDAP 的另一个优点是，在 WebSphere Application Server 使用 LDAP 服务器（通过 LDAP 绑定）进行认证时，您不需要使用 LDAP 管理用户 ID；LDAP 目录中的任何有效的用户 ID 和密码都可以这样使用。另一个方法是使用自定义用户注册表，该注册表在开发环境中使用具有用户 ID 和密码的文件。因此，除了没有权限的用户外，如果取消授予操作系统权限的要求，则 LDAP 和用户自定义注册表都是不错的选择。

问：我应该使用数据库还是使用内存到内存复制来进行会话故障转移？

答：数据库持久化和内存到内存复制之间的性能差异并不大。这是因为 95% 的复制或持久化会话开销是在会话对象的序列化/反序列化中产生的——不论会话保存在哪里，这种开销都必定会产生。另外，当会话对象的大小增加时，性能就会下降——再强调一遍，两种会话分布方式的性能大致相同。

在 IBM WebSphere: Deployment and Advanced Configuration 中，我这样写道：

在此，我想谈一下我的另一个观点。利用内存到内存复制，您可以存储的会话信息的数量受应用服务器的 JVM 堆大小的限制。即使在 WebSphere Application Server V6.01 中支持 64 位的 JVM，最大应用服务器堆大小也大大小于数据库服务器（用作会话存储）上可用的磁盘空间数量。因此，尽管我知道在许多组织中，使用内存到内存复制对避免系统管理员和数据库管理员之间的角色和职责冲突更有利，但我仍持这样一种观点，即数据库持久化仍是最佳选择。

补充
最后，我还要讨论另一个有关会话对象最佳大小的常见问题，但我的一位同事上个月在这个专栏中捷足先登。如果您要问这个问题，则请了解 Bill Hines 都说了些什么。

以上就是我漫无边际的一些想法。我希望在对一些常见询问无法直接回答的情况下，以上内容能帮助您找到适合您环境的最佳回答。