开源 Web 服务器：运营商级 Linux 平台上的性能
ARIES（互联网电子服务器高级研究）项目于 2000 年 1 月在加拿大爱立信研究院启动。其目标是寻找并原型化必要的技术，以证明集群互联网服务器的可行性，该服务器使用 Linux 和开源软件作为基础技术，展示电信级特性。
电信行业内对集群互联网 Linux 服务器的电信级要求非常严格且广为人知。这些特性包括保证的可用性（保证 24/7 访问）、保证的响应时间（统计上保证的延迟）、保证的可扩展性（大规模线性可扩展性）和保证的性能（每秒处理最少数量的事务）。
此外，电信级互联网服务器还需要满足其他重要要求，例如应对互联网流量的爆炸性增长（每六个月增长超过 100%）以及满足最终用户日益增长的服务质量需求，更不用说非常严格的安全级别了。
这些互联网服务器需要高性能且高度可扩展的 Web 服务器。由于 ARIES 的所有工作都基于开源软件，我们需要一个开源 Web 服务器来帮助我们构建目标系统。
我们在 ARIES 中的目标之一是能够构建一个能够扩展到数千个并发用户的互联网服务器，而下载速度不会明显减慢。当应用程序服务器托管在一组或集群服务器上时，这种类型的可扩展性是最佳的。当请求特定网页的请求进入时，该请求将被路由到最不繁忙的服务器（使用智能高效的流量分配解决方案，无论是基于硬件还是软件）。
我们决定尝试使用三个 Web 服务器：Apache、Jigsaw 和 Tomcat。Apache 是世界上最流行的 Web 服务器。自 ARIES 于 2000 年首次启动以来，我们一直在对其进行实验。Jigsaw 是一种基于 Java 的 Web 服务器，目前在我们的实验性 Linux 集群平台上使用。Tomcat 是另一种基于 Java 的 Web 服务器，如果证明其性能更好，则有可能替代 Jigsaw。
Apache Web 服务器是一个强大、灵活、符合 HTTP/1.1 标准的 Web 服务器。根据 Netcraft Web 服务器调查，自 1996 年 4 月以来，Apache 一直是互联网上最流行的 Web 服务器。这并不令人意外，因为它具有许多特性，例如能够在各种平台上运行、其可靠性、稳健性、可配置性以及它提供带有非限制性许可证的完整源代码。对于我们的测试，我们使用了 Apache 1.3.14，这是当时的稳定版本，以及 Apache 2.08 alpha 版本 (2.08a)。
Jigsaw 是 W3C 的开源项目，始于 1996 年 5 月。它是一个 Web 服务器平台，在 Java 中实现的高级架构之上，提供了 HTTP 1.1 实现示例和各种其他功能。Jigsaw 的设计目的是作为技术演示来实验新技术，而不是作为成熟的版本发布。对于我们的测试，我们结合 Java 2 SDK 使用了 Jigsaw 2.0.1（在端口 8001 上提供 HTTP 请求）。
Tomcat 是 Java Servlet 2.2 和 JavaServer Pages 1.1 技术的参考实现。Tomcat 在 Apache 许可证下开发，是一个 servlet 容器，一个运行时 shell，它代表用户管理和调用 servlet，并具有 JSP 环境。
Tomcat 既可以作为独立服务器使用，也可以作为现有 Web 服务器（如 Apache）的附加组件使用。对于我们的测试，我们安装了 Tomcat 3.1 作为独立服务器，在端口 8080 上提供服务请求。
为了测试和评估上述 Web 服务器，我们建立了一个典型的爱立信研究院 Linux 集群平台（参见图 1）。
图 1. 爱立信研究院典型的 Linux 集群
该平台的目标是运营商级服务器应用程序。测试环境包括：
八个无盘 Pentium III CompactPCI CPU 卡，运行频率为 500MHz，配备 512MB RAM。CPU 有两个板载以太网端口，并与一个四端口 ZNYX 以太网卡配对，提供高水平的网络可用性。
八个 CPU，配置与其他 CPU 相同，只是这些 CPU 中的每一个都有一个磁盘组。磁盘组由三个 18GB SCSI 磁盘组成，配置为 RAID 1 和 RAID 5，以提供高数据可用性。
主节点：两个 CPU（带磁盘）充当其他 CPU 的冗余 NFS、NTP、DHCP 和 TFTP 服务器。NFS 冗余代码是在内部开发的，还有一个特殊的挂载程序，允许在同一挂载点挂载两个 NFS 服务器。
当我们启动 CPU 时，它们从 LAN 启动（LAN 1 或 LAN 2，以提高任一 LAN 发生故障时的可用性）。然后，它们向网络上的所有地址广播 DHCP 请求。主节点将回复 DHCP 提议，并将向 CPU 发送它们配置网络设置所需的信息，例如 IP 地址（每个接口一个：eth0、eth1、znb0 和 znb1）、网关、子网掩码、域名、引导服务器的 IP 地址和引导文件的名称。
无盘 CPU 然后将下载并引导 DHCP 配置文件中指定的引导文件，该文件是位于 DHCP 服务器上 /tftpboot 目录下的内核映像。接下来，CPU 将下载 RAM 磁盘并启动应用程序服务器，即 Apache、Jigsaw 和 Tomcat Web 服务器。从启动到获得登录提示，启动无盘服务器的过程不到一分钟。
至于带磁盘的 CPU，它们将下载并引导 DHCP 配置文件中指定的引导文件，该文件是位于 DHCP 服务器上 /tftpboot 目录下的内核映像。接下来，它们将执行自动 RAID 设置和 Red Hat 6.2 的自定义安装。当 CPU 启动后，它们将启动 Apache、Jigsaw 和 Tomcat Web 服务器，每个服务器都在不同的端口上。从启动到获得登录提示，启动磁盘服务器的过程大约需要五分钟（包括自动 RAID 1 和 RAID 5 设置，以及从头开始完整安装 Red Hat 6.2）。
对于我们的测试，我们以无盘 CPU 的方式引导磁盘 CPU（其中六个，除了主节点），以便我们在许多 CPU 上拥有相同的设置。
Web 服务器和客户端-服务器系统的性能取决于许多因素：客户端平台、客户端软件、服务器平台、服务器软件、网络和网络协议。Web 的大多数性能分析都集中在两个主要问题上：整体网络性能和 Web 服务器软件和平台的性能。
我们的基准测试包括一种机制，用于生成受控的 Web 请求流，并使用标准指标报告结果。我们使用了 16 个英特尔赛扬 500MHz 1U 机架式单元（参见图 2），它们配备 512MB RAM 并运行 Windows NT。这些机器使用 WebBench 生成流量，WebBench 是一个从 www.zdnet.com 获得的免费软件工具。
图 2. 基准测试单元
基本的基准测试场景是一组客户端程序（负载生成器），它们发出 Web 请求流并测量系统响应。请求流称为工作负载。WebBench 提供了一种测量 Web 服务器性能的方法。它由一个控制器和多个客户端组成（参见图 3）。控制器提供设置、启动、停止和监控 WebBench 测试的方法。它还负责收集和分析从客户端报告的数据。
图 3. WebBench 的架构
另一方面，客户端执行 WebBench 测试并向服务器发送请求。WebBench 使用客户端 PC 模拟 Web 浏览器。但是，与实际浏览器不同，客户端不显示服务器发送的响应其请求的文件。相反，当客户端收到来自服务器的响应时，它会记录与响应关联的信息，然后立即向服务器发送另一个请求。
Web 服务器有多种测量方法。对于我们的测试，我们将报告每秒服务的连接数或请求数以及吞吐量，即每秒服务的字节数（参见图 4）。
图 4. WebBench 控制窗口
WebBench 使用标准工作负载树来对服务器进行基准测试。工作负载树以压缩文件形式提供，我们需要将其移动到服务器并在 Web 服务器上的 HTML 文档根目录中展开（这是 Web 服务器查找其 HTML 文件的地方）。这将创建一个名为 WBTREE 的目录，其中包含 61MB 的 Web 文档，这些文档将由 WebBench 客户端请求。由于我们的一些 CPU 是无盘的，因此我们将工作负载树安装在 NFS 服务器上，并修改了 Web 服务器配置以使用 NFS 目录作为其文档根目录。
作为 WebBench 配置的一部分，我们指定基准测试机器生成的流量将在目标 CPU 之间平均分配。图 5 显示了我们如何指定每个服务器节点及其将接收的流量百分比。
图 5. WebBench 配置示例
在设置好我们的 Linux 集群和基准测试环境后，我们准备定义我们的测试用例。我们测试了所有三个 Web 服务器（Apache 1.3.14 和 2.08a、Tomcat 3.1 和 Jigsaw 2.0.1），它们在 1、2、4、6、8、10 和 12 个 CPU 上运行。对于每个测试用例，我们都会在 CPU 加载的 RAM 磁盘中指定在加载 RAM 磁盘时启动哪个 Web 服务器。因此，我们运行了四种类型的测试，每种测试使用不同的服务器并在多个 CPU 上进行。
出于本文的目的，我们将仅展示三个比较案例：一个 CPU 上的 Apache 1.3.14 与 Apache 2.08a，八个 CPU 上的 Apache 1.3.14 与 Apache 2.08a，以及一个 CPU 上的 Jigsaw 2.0.1 与 Tomcat 3.1。
我们做的第一个基准测试是在一个 CPU 上测试所有 Web 服务器。在 WebBench 配置中，我们指定所有客户端生成的所有流量都定向到一个 CPU。图 6 显示了最多 64 个并发客户端的基准测试结果。平均而言，Apache 1.3.14 每秒能够处理 828 个请求，而 Apache 2.08a 每秒能够处理 846 个请求。最新的版本显示性能提高了 2.1%。
图 6. 一个 CPU 上 Apache 1.3.14/2.08a 基准测试数据
图 7 绘制了 Apache 1.3.14 和 Apache 2.08a 的基准测试结果。正如我们所看到的，两个服务器的性能几乎相同。
图 7. 一个 CPU 上 Apache 1.3.14/Apache 2.08a 基准测试结果
至于基于 Java 的 Web 服务器 Tomcat 和 Jigsaw，图 8 和图 9 显示了生成的基准测试数据。Jigsaw 能够达到的每秒最大请求数为 39，而 Tomcat 为 60。我们对 Jigsaw 的性能感到惊讶；但是，我们需要记住，Jigsaw 的设计目的是实验新技术，而不是作为用于工业部署的高性能 Web 服务器。
图 8. 一个 CPU 上 Tomcat/Jigsaw 基准测试数据
图 9. 一个 CPU 上 Tomcat/Jigsaw 基准测试结果
当我们将测试扩展到八个 CPU 时，Apache 2.08a 的性能更加稳定，随着我们增加并发客户端的数量，每秒服务的请求数更多，而服务的请求数没有任何波动（参见图 10）。
图 10. 八个 CPU 上 Apache 2.08a/Apache 1.3.14 基准测试数据
图 11 清楚地显示了 Apache 2.08a 与 Apache 1.3.14 相比的稳定性。在八个 CPU 上，Apache 2.08a 能够保持平均每秒 4,434 个请求，而 Apache 1.3.14 为 4,152 个，性能提高了 6.8%。
图 11. 八个 CPU 上 Apache 2.08a/Apache 1.3.14 基准测试结果
我们收集了具有 1、2、4、6、8、10 和 12 个 Linux 处理器的系统的图表。对于每个图表，我们记录了每种配置可以服务的每秒最大请求数。当我们将这个数字除以 Linux 处理器的数量时，我们得到每个处理器在每种配置中每秒可以处理的最大请求数。
图 12 和图 13 显示了针对 Apache 两个版本的每个处理器的事务处理能力与集群大小的关系图。在两个图中，线条都不是平坦的，这意味着可扩展性不是线性的，即不是最佳的。
图 12. Apache 2.08a 可扩展性图表
图 13. Apache 1.3.14 可扩展性图表
如果我们收集 Apache 1.3.14 和 2.08a 的可扩展性数据（参见图 14）并创建相应的图表，图 15，我们会观察到，与彼此相比，两个服务器具有相似的可扩展性。
图 14. 可扩展性数据比较
图 15. Apache 1.3.14 与 2.08a 可扩展性
在 Linux 系统上，两个版本的服务器都具有相似的可扩展性。根据我们的结果，Apache 2.08a 的可扩展性比 1.3.14 版本高约 2%。在任何一种情况下，我们都有缓慢的线性下降。在我们达到八个 CPU 后添加的 CPU 越多，每个 CPU 获得的性能就越低。
至于基于 Java 的 Web 服务器，尽管 Tomcat 显示出比 Jigsaw 更好的性能（每秒处理更多请求），但它显示出轻微的可扩展性问题。图 16 显示，随着我们添加更多处理器，每个处理器的性能略有下降。
图 16. Tomcat 可扩展性图表
尽管如此，对于随着更多处理器的添加而导致的可扩展性下降，有许多可能的解释。
有几个因素可能影响了基准测试的结果：
我们使用 NFS 存储 WebBench 的工作负载树，使其可用于所有 CPU。当每秒数百个客户端尝试访问 NFS 存储的文件时，这可能会在 NFS 级别造成瓶颈。
Jigsaw 和 Tomcat 是基于 Java 的 Web 服务器，因此它们的性能很大程度上取决于 Java 虚拟机的性能，Java 虚拟机也是从 NFS 分区启动的（因为 CPU 是无盘的，并通过 NFS 共享 I/O 空间）。
为了生成 Web 流量，我们仅限于 16 个赛扬机架式单元。生成的流量可能不足以使 CPU 饱和，尤其是在我们测试超过六个 CPU 的 Apache 的情况下。
在我们从事这项活动期间，我们遇到了许多问题，从硬件问题和使用原型硬件到软件问题，例如支持的驱动程序和设备。在本节中，我们将仅关注我们在完成基准测试时遇到的问题。
我们遇到了 ZNYX 以太网 Linux 驱动程序的稳定性问题。驱动程序仍在开发中；它们还不是生产级别。在达到每秒大量事务后，驱动程序将直接崩溃。以下是在一个运行 Apache 2.08a 的 CPU 上的基准测试示例。一旦 CPU 达到每秒处理 1,053 个请求的水平（每秒吞吐量为 6,044,916 字节），以太网驱动程序就会崩溃，我们将失去与 ZNYX 端口的连接（参见图 17）。
图 17. 以太网驱动程序在高负载下崩溃
我们与 ZNYX 的人员进行了大量测试和调试，并且我们能够修复驱动程序问题并保持高水平的吞吐量而不会发生任何崩溃。
我们启动集群时面临的第二个问题与 inetd 有关。inetd 守护程序充当其他系统守护程序的运算符。它在后台运行并侦听网络端口上的传入连接。建立连接后，inetd 会为该端口生成适当守护程序的副本。我们面临的问题是 inetd 由于未知原因阻塞了 UDP 请求，我们需要每次阻塞时重新启动守护程序。即使使用最新版本的 xinetd，我们仍然遇到这个问题。
我们面临的另一个问题是我们无法用足够的流量使 CPU 饱和。这很明显。我们需要比我们尝试基准测试的更多的功率。在我们进行此活动时，我们仅部署了 17 台机器（一个控制器和 16 个客户端）用于基准测试目的。这可能是我们无法扩展的一个原因。但是，我们已将基准测试环境的容量增加到 63 台机器，现在我们将能够重新运行一些测试并验证我们的结果。
ARIES 最初是一个概念验证项目，旨在研究我们是否可以使用 Linux 和开源软件作为基础技术构建具有接近电信级特性的互联网服务器。我们已经试验了各种 Linux 发行版、Web 和流媒体服务器、流量分配和负载均衡方案、适用于 HA Linux 集群的分布式和日志文件系统以及冗余解决方案（NFS、以太网、软件 RAID）。
展望未来，ARIES 的工作将 направлено 增强 Linux 的集群功能，使系统能够容纳更多类型的移动互联网服务，除了迄今为止已部署的 Web 服务器应用程序。重点将是使系统达到集群资源的最佳利用率，并增强移动互联网服务器内需要的安全方面。此外，该项目将通过支持 IPv6 技术来增强现有系统的功能。
我们正在我们的实验性 Linux 集群平台上保留所有三个 Web 服务器。经过测试的 Web 服务器在添加更多 CPU 时并没有线性扩展。但是，它们展示了非常好的性能和接近线性的可扩展性（测试仅限于 12 个 CPU）。我们目前正在部署最新版本的 Apache (2.0.15a)、Jigsaw (2.2.0) 和 Tomcat (3.2)。
根据我们的测试，我们认为 Apache 已被证明比其他 Web 服务器更快且更稳定。我们期待测试和实验 2.0 发布版本，该版本承诺提供干净的代码、结构良好的 I/O 分层和大大增强的可扩展性。
Ibrahim F. Haddad (ibrahim.haddad@ericsson.com) 在爱立信研究院蒙特利尔开放架构实验室工作，研究实时全 IP 网络中的运营商级服务器节点。他目前是康考迪亚大学计算机科学博士候选人。
