Apache与Nginx哪个做站性能更好？2022性能最新对比评测

Apache与Nginx是目前最热门的拿来做对比的内容之一（自从Nginx发布以来），因为这两个都是最常见的网络服务器之一，其次是LiteSpeed和OpenLiteSpeed。而Apache和Nginx为世界上几乎60%的网站提供服务。Apache和Nginx在性能和功能方面是相似的。另一方面，它们的架构、安全和性能都是不同的。

刚开始做站的小伙伴在这两个服务器之间进行选择可能会觉得很困难，因为它们都很优秀。因为每个网络服务器都有自己的优势和劣势，所以尽可能做出最好的选择是很关键的。这里搬主题就给出最新的性能对比评测。

Apache与Nginx的速度比较

在深入探讨Apache与Nginx的对比之前，我们将首先做一个简单的速度测试，我们将在以下场景中进行测试。

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

我们之前也使用同样的程序来测试OpenLiteSpeed与Nginx，而OpenLiteSpeed确实是Nginx的伟大替代品，因为它也支持基本的.htaccess重写规则，因此你可以轻松地从Apache转移到OpenLiteSpeed。

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

最后的结论：两个服务器在小的静态文件方面表现相同。

Apache

Nginx

静态文件大小为1MB

最后的结论：Nginx显然在大型静态文件方面获胜。

Apache

Nginx

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

最终结论：两台服务器在hello world PHP应用程序中的表现相同。

Apache

Nginx

对WordPress的Apache与Nginx进行基准测试

最后的结论：Nginx显然在一个WordPress网站上获胜。

Apache

Nginx

测试结果 – Apache vs Nginx

在测试中我们可以看到，Nginx在速度方面相对来说比Apache要好。其结果是

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

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

2. 测试一个1MB大小的静态文件。

在这个测试中，我们看到Nginx的速度比Apache要好得多，而且是优势很明显。Nginx给出的平均响应时间要少得多。

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

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

4. 测试WordPress的Apache与Nginx

在这个测试中，我们看到Nginx的平均响应时间比Apache的要少得多，所以它的速度比Nginx的要快。

Apache

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

连接处理架构

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

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

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

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

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

分布式配置与集中式配置

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

由于这些文件位于内容文件夹中，Apache在请求文件的路径的每个组成部分中寻找一个.htaccess文件，并应用在那里发现的指令。这有效地实现了分散的网络服务器设置，这通常用于URL重写、访问限制、授权和认证，甚至是缓存策略。

虽然前面所有的例子都可以在Apache的主配置文件中设置，但.htaccess文件提供了一些优势。首先，由于它们在每次沿请求路径遇到时都会被评估，它们的实施不需要重新加载服务器。第二，它使非特权用户能够控制他们自己的网络内容的特定部分，而不给他们对配置文件的完全权力。

某些网络软件，如内容管理系统，现在可以轻松地定制他们的环境，而不需要访问中央配置文件。共享主机供应商利用这一点来保持对核心设置的控制，同时向客户提供对其特定目录的访问。

基于文件和URI的解释

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

因为Apache从一开始就是作为一个网络服务器建立的，所以它默认将请求解释为文件系统资源。要找到一个实际的文件，它从文件根开始，并在主机和端口号后面加上请求的部分。在网络上，文件系统的层次结构基本上是由可用的文件树代表的。

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

尽管Apache可以在底层文件系统和网络空间上工作，但它更倾向于使用文件系统技术。一些设计决定反映了这一点，例如使用.htaccess文件进行每个目录的设置。

模块

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

这个功能被Apache用于广泛的任务。由于该平台的成熟，它附带了一个大型的模块库。例如，Mod PHP将一个PHP解释器嵌入到每个正在运行的工作者中，并可用于改变服务器的部分基本功能。

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

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

因为Apache已经使用了很长时间，所以对它有很多软硬件的支持。对于核心服务器和涉及将Apache连接到其他软件的基于任务的情况，可以获得大量的第一和第三方文档库。

许多工具和网络项目都包含了在Apache环境下启动自己的工具，此外还有文档。这可能是在项目本身中提供的，也可能是在你的发行版的打包团队所维护的软件包中。

由于它的市场份额和它已经存在的时间，Apache一般来说会从第三方项目中得到更多的支持。管理员也更有可能使用过Apache，这不仅仅是因为它的广泛使用，还因为许多人在共享主机环境中开始他们的职业生涯，由于.htaccess的分布式管理功能，Apache几乎是唯一使用的。

Apache的优势

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

• – 对于服务动态内容，性能很好。
• – 动态加载和卸载模块。
• – 提供一个每个目录的.htaccess文件，可以用来推翻全系统的设置。
• – 支持和文件都很出色。
• – 该模型使用每进程一个连接的方法。
• – 它包括mod_evasive和mod_security模块，它们增加了额外的安全层。

Apache的劣势

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

Nginx

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

• – 一个HTTP缓存和一个负载平衡器
• – Apache和其他Web服务器的前端代理。
• – HTTP、HTTPS、SMTP、POP3和IMAP协议都是由这个反向代理服务器提供服务。

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

连接处理架构

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

Nginx生成工作进程，每个工作进程能够处理数以万计的连接。工作者进程通过开发一个快速的循环机制，定期检查和处理事件来实现这一目标。通过将实际工作与连接解耦，每个工作者只有在新的事件发生时才能关注一个连接。工作者的每个连接都被置于事件循环中，在那里它们与其他连接共存。事件在循环中被异步处理，允许以非阻塞的方式进行工作。循环关闭后，该连接被从循环中删除。

由于其连接处理方法，Nginx可以用最小的资源进行特别大的扩展。因为服务器是单线程的，没有产生额外的进程来处理每个新的连接，所以内存和CPU的使用保持相对稳定，即使服务器处于巨大的压力之下。

静态与动态内容

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

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

另一方面，这种策略也有一些好处。动态解释器的开销将只存在于动态内容中，因为它不包括在工作者进程中。静态内容可以直接发送，只有在必要时才咨询解释器。这在Apache中也是可行的，但它消除了上一节中提到的好处。

分布式配置与集中式配置

Nginx不理解.htaccess文件，也没有办法在主配置文件之外评估每个目录的配置。尽管不如Apache的方法通用，但它有自己的一套好处。

与目录级设置的.htaccess方法相比，提高性能是最明显的好处。对于每个请求，服务器将在标准的Apache设置中，检查通往请求文件的每个父目录中的这些文件，允许在任何目录中设置.htaccess。如果这个搜索发现了一个或多个.htaccess文件，就必须对它们进行读取和处理。Nginx通过对每个请求执行单一的目录查询和文件读取，不允许目录覆盖（假设在传统的目录结构中找到文件），可以更快地提供请求。

另一个好处是，它是安全的。分布式的目录级配置访问也将安全责任分散到各个用户身上，这些用户可能被信任，也可能不被信任，无法正确操作。通过确保管理员对Web服务器有完全的控制权，你可以避免在授予他人访问权时可能出现的一些安全失误。

如果你担心这些问题，请记住，你可以禁用Apache中的.htaccess配置。

文件与基于URI的解释

Nginx被设计成一个网络服务器以及一个代理服务器。由于这两项工作所需的架构，它主要是用URI工作，必要时翻译成文件系统。

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

例如，服务器和位置块，是Nginx最重要的配置块。服务器块负责解释请求的主机，而位置块则负责在主机和端口之后匹配URI的部分。现在，请求被当作一个URI而不是一个文件系统的位置来处理。

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

这可能看起来很相似，但把请求主要解释为URI而不是文件系统的位置，使得Nginx更容易作为一个网络、邮件和代理服务器。Nginx是通过定义它应该如何响应某些请求模式来设置的。Nginx在准备交付请求之前不会检查文件系统，这就是为什么不支持.htaccess文件。

模块

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

另一方面，Nginx模块仍然相当有价值，因为它们允许你只包括你想使用的功能，从而准确地指定你对服务器的要求。一些用户可能还认为这种方法更安全，因为任意的组件不能连接到服务器上。如果你的服务器曾经被放在一个可以想象的情况下，它几乎肯定已经被破坏了。

Nginx模块中的许多功能与Apache模块中的相同。代理支持、压缩、速率限制、日志、重写、地理定位、认证、加密、流媒体和邮件功能都可以通过Nginx模块实现。

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

由于Nginx的高性能，越来越多的人使用它，因此它越来越受欢迎，但它在某些关键领域仍有一些需要追赶的地方。

由于早期的开发和文档大多是用俄语编写的，所以过去很难找到Nginx的大量英语文档。随着人们对该项目兴趣的增加，该文档也得到了充实，目前在Nginx网站上和通过第三方有很多管理资源。

对第三方应用程序的支持和文档越来越广泛，软件包维护者也开始提供在某些情况下自动配置Apache和Nginx的选项。配置Nginx与其他软件一起运行通常很简单，即使没有支持，只要项目的需求被记录下来（权限、头部文件等）。

Nginx的优点

Nginx网络服务器简单、轻便、快速。专门为高流量的网站设计。

• – 使用一个事件驱动的非阻塞架构，使用较少的CPU和内存。
• – 它包括大量针对静态内容的优化和服务选项。因此，它为静态内容提供的服务比Apache快2.5倍，使用的内存更少。
• – 它在多处理器系统中的表现令人赞叹。
• – DDoS攻击可以通过一个内置的配置选项来防止。

Nginx的劣势

• – 动态内容不能被原生处理。
• – 可用的模块数量较少。
• – 支持Linux和Unix操作系统，但对Windows的支持受到限制。
• – Apache支持的.htaccess文件，Nginx不支持。
• – 稀缺的日志监控软件 – 简单地将日志保存在文件中，必须手动浏览。

将Apache和Nginx结合使用

在介绍了Apache和Nginx的优点和缺点之后，你应该能够确定哪一个服务器更适合你的需求。然而许多用户发现，同时使用两个服务器可以让他们利用每个服务器的优势。

这种合作的标准配置是在Apache前面使用Nginx作为一个反向代理。这将使Nginx能够处理所有的客户请求。这就利用了Nginx的快速处理速度和同时管理大量连接的能力。

对于Nginx擅长的静态内容，文件将被迅速并直接提供给客户端。Nginx将把动态内容的请求，如PHP脚本，代理给Apache，后者将处理结果并提供渲染的页面。然后，该材料可以通过Nginx返回给客户端。

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

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

什么时候使用Apache与Nginx？

如本篇所述，Apache和Nginx都是功能强大、适应性强、全能型的网络服务器。对于高流量的网站，Apache最适合提供动态站点，而Nginx最适合提供静态内容或媒体流，就是这么简单。

什么时候可以使用Apache

• – 如果你在一个共享主机计划上。
• – 如果你欣赏一个拥有众多资源的有益社区，这就是你要去的地方。
• – Apache在网络开发者中很受欢迎，因为它的设置很简单。

什么时候可以使用Nginx

• – 如果你有一个VPS或专用服务器。
• – 你是一个有大量静态内容的流行网站的所有者。
• – 如果你想管理传入的流量并将其分配给速度较慢的上游服务器。

Apache与Nginx：2022年你应该怎么选？

无论你的托管公司提供哪一种，在许多情况下，你将没有选择。毕竟许多网络供应商遵循同样的策略，如果你在Apache与Nginx之间做出决定，你应该遵循这个策略。

• – 如果你想托管一个需要不断设置的服务器，或者你想给用户一个配置选项，Apache是一个不错的选择。
• – 另一方面，如果你想获得超快的性能、坚如磐石的安全性以及管理配置而不是用户的能力，那么Nginx就是你的选择。

由于它的基本架构，Apache在性能方面可以占用更多的内存。在高流量的情况下，Nginx的性能会更好，特别是在有大量静态材料需要管理的情况下。

因此，如果你依靠缓存来存储和提供内容，Nginx可能是理想的解决方案。记住，Nginx不适合提供动态内容；因此你的性能将受到你的服务器所利用的代理的有效性的影响。

最后总结

正如你所看到的，Apache以及Nginx都很强大，适应性强，而且能力强。你可以评估你的个人需求和测试你期望看到的模式是选择适合你的服务器的主要标准。

在这些项目中，在原始性能、能力以及实施每个项目所需的时间方面存在着显著的差异。然而，通常情况下，它们是一系列权衡的结果，不应该被忽视。最后但并非最不重要的是，不存在一刀切的网络服务器，所以要你要根据你的站点使用方向，再选择适合你的需求的方案。