为什么Nginx如此之快？

您可能会看到这个演示文稿来概述nginx内部。 主要区别是请求的asynchronous处理，而不是像Apache那样使用线程。 你也可以看看这个文档 。

像漫步者这样的网站如何快速地提供dynamic内容？ …这纯粹是Nginx的能力吗？ 我应该在哪里研究这些function？

这与使用的Web服务器几乎没有任何关系–Nginx，IIS和Apache都是“足够快”，通常在几毫秒内完成工作。 nginx比Apache快得多，但这仅仅意味着网站所有者将需要更less的服务器来完成Web服务–Nginx不会更快地向您传输数据。

不太重要的部分是服务器端的速度 ，即创buildHTML的时间。 更重要的部分是“前端”的performance ，我指的是HTML，CSS，Javascript和Images，这些的数量，这些的大小，以及这些的正确传递（HTTP压缩，caching）。

当然，服务器端的速度依然很重要，我不是说应该忽略它，也不要紧。 但通常情况下，它是最终用户速度最小的部分 – 服务器端的工作通常在500毫秒内完成，但是在3000 – 5000毫秒之前，页面还没有准备好。 大部分时间用于下载前端资源（CSS，Javascript，图像）。

史蒂夫·苏德斯（Steve Souders）在雅虎时做过原创工作，现在在Google工作。 他的第一本书“高性能网站”是了解更多快速网站的最佳起点。 在这本video演讲中 ，可以find他书中同样的材料和这些devise规则 。 不过，我发现这本书很快就能阅读，而且更容易理解。

您可以通过WebPageTest.org的testing人员运行这些站点，这会让您对这些站点的前端部分有一个很好的感觉，以及为什么他们会更快或更慢。

我相信，如果从Nginx服务serverfault.com将是更快的IIS 7（假设db访问时间在这两种情况下是相同的）。 这是一个公平的假设吗？

不，那是一个误解。 🙂

Nginx通常用于负载平衡其他应用程序/服务器和提供静态内容，而不是用作完整的服务器。

例如，你可以用许多python框架之一编写一个应用程序，并且让nginx成为许多实例的前端（可能遍布在几台机器上）。 在这种情况下，nginx服务器有两个目的：它直接处理对图像和样式表等静态内容的请求（并且由于它的devise，它可以非常快速地完成），它将dynamic请求传递给应用程序， 。 这在Ruby on Rails社区也是非常stream行的configuration。

还有另外两个可能的原因，为什么漫步者可能会比当地的雅虎服务显得更快。 首先，本地的雅虎PoP可能没有足够的资源来满足更快的请求数量，所以也许简单地增加更多的硬件（假设软件以这种方式很好地扩展）会加快速度（但是，大概不同的是值得维护额外的工具包或雅虎的成本会做到这一点）。 另一个很大的区别可能在于后端，而不是Web服务器 – 这两个服务无疑会有非常不同的数据库安排，即使它们不可能运行完全相同的各种查询（以及专用于数据库结构的硬件也会有显着的效果）。

分析为什么一个服务比另一个服务（通常或在特定情况下）更快速通常不会导致一个简单的答案 – 有很多方法来devise一个应用程序，旨在扩展到成千上万的用户，每个用户自己的利益，问题和妥协，即使你将所有这些差异因素考虑在内，每个站点都将具有不同的基于用户的dynamic，而且还存在超出devise者控制的networking问题。

最好的网站使用Zeus的ZXTM等应用加速器 – 它们可以在许多情况下cachingdynamic响应，这显然是非常有益的。

nginx可能的但更具扩展性的架构，在静态内容服务器/dynamic内容生成器之前具有合理的负载平衡。 如果你真的想获得很好的最终用户体验，你应该把内容移到“眼球” – 使用一些CDN。

如果你对这个主题感兴趣 – 看看这个和那个 ，好吧 – 谷歌; – ]

这是一个很好的解释： http : //www.aosabook.org/en/nginx.html

我很难看到serverfault更快（因为stream量可能有负载问题？），因为它已经是我的路线在欧盟的即时页面加载。 它比大多数地方新闻网站等更快，更快速响应。

加载时间和延迟的大多数明显问题来自服务器和最终用户之间，而不是实际的服务器性能（除非有人确定大小或devise错误）。 不同的网站可以路由不同的方式，对我来说，一个国家的本地网站比全球的网站有更大的延迟 – 这一切都取决于这么多的variables，你不能说它只能通过服务解决升级/切换，除非你知道这是一个具体的使用问题（R）是…

很明显，在服务器上的各种caching有很大的不同，但据我所知，所有这些网站已经这样做了。