找到HTTP瓶颈

Question

我正在使用Ruby on Rails开发自定义博客应用程序，将加载速度作为衡量成功的主要指标。

我正在缓存（使用Redis）视图和模型，以缩短查询和原始HTML的呈现。最后我成功地在15ms内装了一个帖子。部署时间。

我买了一台Linode 20美元/月的机器，配备2GB内存，2个内核，ssd存储，40gbit，250mbit。该机器在伦敦托管。我安装了Ubuntu 15.04。

我设置了Cloudflare免费计划，以实现更积极的缓存和资产缩减。我启用了完整的SSL功能。

我安装了nginx作为在Unicorn上运行的Rails应用程序的代理。 Rails，Redis，PostgreSQL和nginx在同一台服务器上运行。

我在意大利罗马。最近的Cloudflare数据中心位于米兰，而Linode服务器的起源位于伦敦。平均请求时间（由chrome网络面板报告）为230毫秒。 Whops ...

首先，我检查了Rails日志，并且日志报告的时间（和X-Runtime标头）与我的开发数据一致（<20ms）。

我编辑了nginx配置以添加X-Time标头：

add_header X-Time $request_time;

这显示Rails时间只有几毫秒。

然后我启用了对服务器的直接访问（禁用了Cloudflare）并禁用了SSL以消除了握手开销。

所以我终于发现有或没有Cloudflare，有或没有SSL，加载时间在[180-350] ms范围内总是非常随机，没有明显的解释。

以下是Chrome计时面板的一个镜头，没有Cloudflare和SSL。只是直接在nginx服务器的端口80上的原始HTTP连接。

为什么我在快速应用中看到如此高的时间？我接下来应该检查什么？ Linode服务器是我的瓶颈吗？

由于

修改

看起来像nzx默认启用的gzip压缩使整个事情减慢了30％。我现在禁用它，因为Cloudflare无论如何都会在第二步中对它进行gzip。现在请求时间在120到200毫秒之间，但我仍然觉得可以改进。