Apache vs NGINX - 谁在性能方面获胜？

已发表: 2022-04-02

Apache 与 NGINX 是最热门的争论之一（自 NGINX 发布以来），因为它们都是世界上最常见的 Web 服务器之一，其次是 LiteSpeed 和 OpenLiteSpeed。

Apache 和 NGINX 为全球近 60% 的网站提供支持。 Apache 与 NGINX 在性能和功能方面相似。 另一方面，它们的架构、安全性和性能都是不同的。

在这两个服务器之间进行选择可能很困难，因为它们都很出色。 因为每个 Web 服务器都有自己的优点和缺点，所以尽可能选择最佳选项至关重要。

您还可以在此处查看 openlitespeed 与 nginx 的辩论。

目录

Apache 与 NGINX 速度比较

在深入研究 Apache 与 NGINX 的争论之前。 我们先做一个简单的速度测试，我们将在下面的场景中进行测试。

  • 让我们测试一个 5 KBytes 的小静态文件
  • 1MB大小的静态文件
  • 测试一个简单的 PHP Hello World 应用程序
  • 为 WordPress 对 Apache 和 NGINX 进行基准测试

我们使用相同的程序来测试 openlitespeed 与 nginx。 OpenLiteSpeed 确实是 NGINX 的绝佳替代品，因为它也支持基本的.htaccess重写规则，因此您可以轻松地从 Apache 迁移到 OpenLiteSpeed。

让我们测试一个 5 KBytes 的小静态文件

最终判决：两台服务器的小静态文件执行相同。

阿帕奇

阿帕奇与 NGINX

NGINX

1MB大小的静态文件

最终判决：NGINX 显然赢得了大型静态文件。

阿帕奇

NGINX

测试一个简单的 PHP Hello World 应用程序

最终判决：两台服务器的性能与 hello world php 应用程序相同。

阿帕奇

NGINX

为 WordPress 对 Apache 和 NGINX 进行基准测试

最终判决：NGINX 显然赢得了 WordPress 网站。 您可以使用本指南来加快您的 WooCommerce 商店

阿帕奇

NGINX

测试结果 - Apache vs NGINX

正如我们在测试中看到的，NGINX 在速度方面相对优于 Apache。 结果是：

1.测试一个5KBytes的小静态文件：

在这个测试中，我们看到 Apache 和 NGINX 都给出了相对相同的结果。

2. 测试一个大小为 1MB 的大型静态文件：

在本次测试中，我们看到 NGINX 的速度比 Apache 快多了。 NGINX 的平均响应时间要短得多。

3. 测试一个简单的 PHP Hello World 应用程序

在这个测试中，我们看到 Apache 和 NGINX 都给出了相对相同的结果。

4. 为 WordPress 测试 Apache 与 NGINX

在这个测试中，我们看到 NGINX 的平均响应时间比 Apache 短得多，因此它的速度比 NGINX 更快。

阿帕奇

有一个开发人员社区将 Apache 维护为开源 Web 服务器。 它使用流程驱动的架构，为每个连接请求创建一个新线程。
此外，Apache 提供了多种可用于增加 Web 服务器功能的模块。 Apache 快速、可靠、安全且高度可定制，通过使用扩展和模块来满足不同环境的需求。

连接处理架构

Apache 有许多控制如何处理客户端请求的多处理模块（Apache 称为 MPM）。 从本质上讲，这使管理员能够快速切换连接处理架构。

  • mpm-Prefor：这个多处理模块 (MPM) 实现了一个非线程的预分叉 Web 服务器。 每个服务器进程都可以响应传入的请求，并且服务器池的大小由父进程管理。 它适用于需要避免线程以使用非线程安全库的站点。 它也是隔离每个请求的最佳 MPM，确保一个问题不会影响其他请求。
  • mpm-worker：一个混合多进程多线程服务器由这个多处理模块（MPM）实现。 与基于进程的服务器相比，它可以使用更少的系统资源来处理大量请求，因为它使用线程来传递请求。 通过保持许多进程可用，每个进程都有许多线程，它保留了基于进程的服务器的大部分稳定性。
  • mpm-event：事件多处理模块 (MPM) 旨在通过将某些处理委托给侦听器线程来允许同时处理多个请求，从而释放工作线程以服务新请求。
    Apache 具有灵活的设计，允许您从各种连接和请求处理算法中进行选择。 随着互联网格局的变化，所呈现的选择主要是服务器发展和并发需求增加的产物。

静态与动态内容

Apache 服务器可以使用其标准的基于文件的机制来处理静态内容。 上述 MPM 方法主要负责这些程序的执行。

Apache 可以通过在其每个工作实例中包含特定于语言的处理器来额外处理动态内容。 这使它能够在不使用 Web 服务器内的外部组件的情况下执行动态内容。 动态可加载模块可用于启用这些动态处理器。

因为 Apache 可以在内部处理动态内容，动态处理配置通常更容易。 如果内容需求发生变化，模块可以很容易地被替换，并且通信不需要与额外的软件协调。

分布式与集中式配置

通过分析和解释内容文件夹本身的隐藏文件中的指令，Apache 添加了一个选项以允许在每个目录的基础上进行进一步配置。 .htaccess文件是这些文件的名称。

因为这些文件位于内容文件夹中，Apache 在请求文件的路径的每个组件中查找.htaccess文件并应用在那里找到的指令。 这有效地实现了分散式 Web 服务器设置，这通常用于 URL 重写、访问限制、授权和身份验证，甚至缓存策略。

虽然前面的所有示例都可以在主 Apache 配置文件中设置，但.htaccess文件提供了许多优点。 首先，因为每次在请求路径中遇到它们时都会对其进行评估，因此无需重新加载服务器即可实现它们。 其次，它使非特权用户能够控制他们自己的 Web 内容的特定部分，而无需授予他们对配置文件的完全权限。

某些 Web 软件（例如内容管理系统）现在可以轻松自定义其环境，而无需访问中央配置文件。 共享主机提供商利用它来控制核心设置，同时为客户提供对其特定目录的访问权限。

文件与基于 URI 的解释

Apache 可以将请求解释为物理文件系统资源或需要更抽象评估的 URI 目标。 一般来说，Apache 使用<Directory>或<File>块作为前者，而<Location>块用于更抽象的资源。

因为 Apache 是从头开始构建为 Web 服务器的，所以默认情况下它将请求解释为文件系统资源。 要查找实际文件，它从文档根目录开始，并在主机和端口号之后附加请求部分。 在 Web 上，文件系统层次结构本质上由可用的文档树表示。

当请求与底层文件系统不匹配时，Apache 提供了许多选项。 例如，别名指令可用于映射到不同的位置。 使用<Location>块而不是文件系统允许您直接使用 URI。 正则表达式变体也可用于在文件系统中更灵活地应用配置。

尽管 Apache 可以在底层文件系统和 webspace 上工作，但它更喜欢使用文件系统技术。 一些设计决策反映了这一点，例如使用 .htaccess 文件进行每个目录的设置。

模数

Apache 中的模块系统允许您在服务器运行时动态加载和卸载模块以满足您的需求。 Apache 核心始终存在，但可以启用或禁用模块、添加或删除功能以及连接到主服务器。

这个特性被 Apache 用于广泛的任务。 由于平台的成熟，它带有一个庞大的模块库。 例如，Mod php 将 PHP 解释器嵌入到每个正在运行的 worker 中，并可用于更改服务器的部分基本功能。

另一方面，模块不仅仅处理动态内容。 他们可以重写 URL、验证客户端、加固服务器、记录、缓存、压缩、代理、限制速率和加密数据，以及其他功能。 它们可以在不增加大量工作的情况下提供增强的功能。

支持、兼容性、生态系统和文档

因为 Apache 已经存在了这么久，所以对它有很多支持。 对于涉及将 Apache 连接到其他软件的核心服务器和基于任务的情况，可以访问大量的第一方和第三方文档库。

除了文档之外，许多工具和 Web 项目还包含在 Apache 环境中引导自身的工具。 这可能在项目本身或您的发行版的打包团队维护的包中提供。

由于其市场份额和可用时间； Apache 通常会从第三方项目中获得更多支持。 管理员也更有可能使用 Apache，这不仅是因为它的广泛使用，还因为许多人的职业生涯都是在共享主机环境中开始的，由于.htaccess分布式管理功能，Apache 实际上仅在其中使用。

Apache 与 NGINX 的优势

许多网站管理员和开发人员更喜欢 Apache 而不是 NGINX，因为它更老。 它与 Windows、Unix 和 Linux 操作系统兼容。

• 对于提供动态素材，这是一个出色的性能。
• 动态加载和卸载模块。
• 提供每个目录的.htaccess 文件，可用于否决系统范围的设置。
• 出色的支持和文档。
• 该模型使用每个进程一个连接的方法。
• 它包括mod_evasive 和mod_security 模块，增加了额外的安全层。

Apache 与 NGINX 的缺点

• 无法同时处理大量请求。
• 与 NGINX 相比，显示静态内容需要更长的时间。
• 它提供了广泛的设置和管理功能。 因此，它不适合新手。
• 具有大量流量的网站存在性能问题。

NGINX

为了克服“C10k”问题，俄罗斯程序员 Igor Sysoev 发明了 NGINX。 Igor 实现了他的目标：NGINX 可以轻松管理超过 10,000 个并发连接。 为了更好地处理新连接，NGINX 具有事件驱动和异步设计。 NGINX 是一个提供很多功能的 Web 服务器。 下面列出了其中的一些：

• HTTP 缓存和负载平衡器
• Apache 和其他网络服务器的前端代理。
• HTTP、HTTPS、SMTP、POP3 和 IMAP 协议均由该反向代理服务器提供服务。

自发布以来，NGINX 因其低资源使用率和在低成本硬件上有效扩展的能力而越来越受欢迎。 NGINX 是一个 Web 服务器，专门用于快速提供静态材料，旨在将动态请求转发到更适合此类任务的软件。

连接处理架构

NGINX 在 Apache 之后出现，对大规模站点将面临的并发问题有了更好的理解。 NGINX 是使用异步、非阻塞、事件驱动的连接处理算法从头开始构建的，以利用这些信息。

NGINX 生成工作进程，每个工作进程都能够处理数万个连接。 工作进程通过开发一种定期检查和处理事件的快速循环机制来实现这一点。 通过将实际工作与连接分离，每个工作人员只有在发生新事件时才能专注于连接。

每个worker的连接都放置在事件循环中，它们与其他连接共存。 事件在循环内异步处理，允许以非阻塞方式完成工作。 该链接在关闭后从循环中删除。

得益于其连接处理方法，NGINX 可以用最少的资源扩展得非常远。 由于服务器是单线程的，并且不会生成额外的进程来处理每个新连接，因此内存和 CPU 使用率保持相对恒定，即使服务器处于巨大压力下也是如此。

静态与动态内容

NGINX 没有对动态内容处理的原生支持。 NGINX 必须将 PHP 和其他动态内容请求传递给外部处理器进行处理，然后等待返回的渲染内容。 然后可以将结果通知客户。

对于管理员来说，这意味着 NGINX 和处理器之间的通信必须使用 NGINX 理解的协议之一（http、FastCGI、SCGI、uWSGI、memcache）进行配置。 这会使事情变得更复杂一些，尤其是在估计允许的连接数时，因为对处理器的每次调用都需要一个新的连接。

另一方面，这种策略提供了一些好处。 动态解释器的开销只存在于动态材料中，因为它不包含在工作进程中。 静态内容可以以直接的方式发送，仅在必要时咨询口译员。 这对于 Apache 也是可能的，但它消除了上一节中提到的好处。

分布式与集中式配置

NGINX 不理解.htaccess文件，也没有办法在主配置文件之外评估每个目录的配置。 虽然不如 Apache 方法通用，但它有其自身的一组优点。

与目录级设置的.htaccess方法相比，性能的提高是最显着的增益。 对于每个请求，服务器将检查每个父目录中的这些文件，这些文件通向标准 Apache 设置中的请求文件，该设置允许在任何目录中访问.htaccess 。 如果此搜索出现一个或多个.htaccess文件，则必须读取并处理它们。 NGINX 可以通过执行单个目录查询和通过不允许目录覆盖（假设文件在传统目录结构中找到）为每个请求读取文件来更快地服务请求。

另一个好处是它是安全的。 分配目录级配置访问权限还将安全责任分散到各个用户，这些用户可能会或可能不会被信任以正确执行此操作。 通过确保管理员可以完全控制 Web 服务器，您可以避免在授予他人访问权限时可能出现的几个安全错误。

如果您担心这些问题，请记住您可以在 Apache 中禁用.htaccess解释。

文件 VS 基于 URI 的解释

NGINX 被设计为作为 Web 服务器和代理服务器运行。 由于这两个工作所需的架构，它主要与 URI 一起工作，在必要时转换为文件系统。

这可以从某些情况下构建和处理 NGINX 配置文件的方式中看出。
NGINX 没有办法为文件系统目录指定配置，因此它解析 URI。

例如，服务器和位置块是 NGINX 最重要的配置块。 服务器块负责解释请求的主机，而位置块负责匹配主机和端口之后的 URI 部分。 该请求现在作为 URI 而不是文件系统位置进行处理。

对静态文件的所有请求最终都必须映射到磁盘上的某个位置。 NGINX 选择将首先处理请求的服务器和位置块，然后将文档根与 URI 结合起来，根据设置根据需要进行修改。

这可能看起来很相似，但是将请求主要解释为 URI 而不是文件系统位置使 NGINX 更容易用作 Web、邮件和代理服务器。 NGINX 是通过定义它应该如何响应某些请求模式来设置的。 NGINX 在准备好发送请求之前不会检查文件系统，这就是不支持.htaccess文件的原因。

模块

NGINX 也有一个模块系统，但是它与 Apache 的有很大不同。 NGINX 中的模块不能动态加载，因此必须选择它们并编译到核心软件中。
因此，NGINX 对许多用户的适应性将大大降低。 对于那些不愿在其发行版的标准打包方案之外维护自己构建的软件的用户来说尤其如此。 虽然大多数发行版的软件包都包含最常用的模块，但如果您需要非标准模块，则必须自己从源代码构建服务器。

另一方面，NGINX 模块仍然非常有价值，因为它们允许您通过仅包含您想要使用的功能来准确指定您想要从服务器获得的内容。 一些用户可能还认为这种方法更安全，因为无法将任意组件连接到服务器。 如果您的服务器曾经处于可以想象的情况，那么几乎可以肯定它已经受到损害。

NGINX 模块中的许多功能与 Apache 模块中的功能相同。 代理支持、压缩、速率限制、日志记录、重写、地理定位、身份验证、加密、流媒体和邮件功能都可以通过 NGINX 模块获得。

支持、兼容性、生态系统和文档

由于 NGINX 的高性能，随着越来越多的人使用它，NGINX 越来越受欢迎，但它在某些关键领域仍有一些工作要做。

因为大部分早期的开发和文档都是俄语的，过去很难找到 NGINX 的大量英文文档。 随着对该项目的兴趣增加，文档已经充实，并且目前在 NGINX 站点上和通过第三方提供了大量的管理资源。

第三方应用程序的支持和文档变得越来越广泛，并且包维护者开始提供在某些情况下自动配置 Apache 和 NGINX 的选项。 配置 NGINX 以与其他软件一起操作通常很简单，即使没有支持，只要记录项目的需求（权限、标题等）。

NGINX 的优势

NGINX Web 服务器简单、轻量、快速。 专为高流量网站设计。

• 使用事件驱动的非阻塞架构，使用较少的 CPU 和内存。
• 它包括大量针对静态内容的优化和服务选项。 因此，它提供静态内容的速度比 Apache 快 2.5 倍，并且使用的内存更少。
• 它在多处理器系统中表现出色。
• 内置配置选项可防止 DDoS 攻击。

NGINX的缺点

• 无法原生处理动态内容。
• 可用的模块数量较少。
• 支持Linux 和Unix 操作系统，但Windows 支持受到限制。
• NGINX 不支持 Apache 支持的.htaccess文件。
• 缺乏日志监控软件——只需将日志保存到必须手动导航的文件中。

一起使用 Apache 和 NGINX

在查看了 Apache 和 NGINX 的优缺点之后，您应该能够确定哪种服务器更适合您的需求。 然而，许多用户发现同时使用两台服务器可以让他们利用每台服务器的优势。

本次合作的标准配置是使用 NGINX 作为 Apache 前面的反向代理。 这将使 NGINX 能够处理所有客户端请求。 这利用了 NGINX 的快速处理速度和一次管理大量连接的能力。

这些文件将快速直接地提供给客户端以获取 NGINX 擅长的静态内容。 NGINX 将对动态内容（例如 PHP 脚本）的请求代理到 Apache，Apache 将处理结果并提供呈现的页面。 然后可以通过 NGINX 将材料返回给客户端。

对于许多用户来说，这种设计效果很好，因为它允许 NGINX 充当分拣机。 它将处理它可以处理的任何请求并传递那些它不知道如何处理的请求。 我们可以通过减少要求 Apache 服务器处理的请求数量来减少 Apache 进程或线程被占用时发生的一些阻塞。

您可以通过根据需要添加更多后端服务器来扩展这种安排。 NGINX 可以简单地设置为将请求转发到服务器池，从而提高配置的容错性和性能。

何时使用 Apache 与 NGINX？

如本文所述，Apache 和 NGINX 都是功能强大、适应性强且全方位的优秀 Web 服务器。 对于高流量的网站，Apache 最适合提供动态素材，而 NGINX 最适合提供静态内容或媒体流。 就这么简单：

什么时候可以使用 Apache

• 如果您使用共享托管计划。
• 如果您喜欢一个拥有大量资源的乐于助人的社区，那么这里就是您的理想去处。
• Apache 在 Web 开发人员中很受欢迎，因为它设置简单。

什么时候可以使用 NGINX

• 如果您有 VPS 或专用服务器。
• 您是拥有大量静态内容的热门网站的所有者。
• 如果您想管理传入流量并将其分发到速度较慢的上游服务器。

Apache 与 NGINX：2022 年你应该为你的服务器选择哪一个？

您的托管公司提供的任何一个都是您应该使用的。 在许多情况下，您将别无选择。 许多网络提供商都遵循相同的策略，如果您在 Apache 与 NGINX 之间做出决定，您应该遵循这些策略：

• 如果您想托管需要不断设置的服务器，或者如果您想为用户提供配置选项，Apache 是一个不错的选择。
• 另一方面，如果您想要超快的性能、坚如磐石的安全性以及管理配置而不是您的用户的能力，那么 NGINX 是您的最佳选择。

由于其基础架构，Apache 在性能方面可以占用更多 RAM。 在高流量的情况下，NGINX 会表现得更好，尤其是在需要管理大量静态素材的情况下。

如果您依赖缓存来存储和提供内容，NGINX 可能是理想的解决方案。 请记住，NGINX 不能提供动态素材； 因此，您的性能将受到服务器使用的代理的有效性的影响。

结论

如您所见，Apache 和 NGINX 功能强大、适应性强且有能力。 评估您的个人需求并测试您希望看到的模式是为您选择合适服务器的主要标准。

在这些项目中，原始性能、功能和实施每个项目所需的时间存在显着差异。 然而，它们通常是一系列不容忽视的权衡的结果。 最后但同样重要的是，没有万能的 Web 服务器，因此请选择适合您需求的选项。