文件服务器文件加载较慢的解决方案（CDN+Nginx）

Posted 2023-05-04

参考技术A

通过nginx解决图片加载较慢，连接数较多，宽带占用的问题。可以通过简单配置达到目的，主要配置以下几项内容：

小结： 也许是我对nginx的基础以及理解不够全面，但是我觉得宽带因素等条件都摆在那里，在同一台文件服务器上也只能是限制客户端的连接来进行优化。所以只是简单做了优化后久没有深化研究，而且我们的文件服务器上的文件也不少。

CDN(Content Delivery Network): 内容分发网络，通过cdn访问文件服务器时，cdn会将文件缓存到cdn服务器，下一次访问该文件时，就直接从cdn的缓存服务器上获取文件，而不需要到文件服务器获取文件。具体的知识介绍可参考 百度百科 。

阿里云的CDN介绍：内容分发网络（Content Delivery Network，CDN）是建立并覆盖在承载网上，由不同区域的服务器组成的分布式网络。将源站资源缓存到全国各地的边缘服务器，供用户就近获取，降低源站压力。

根据文档中阿里云在国内拥有2300+节点，所有节点均接入万兆网卡，单节点存储容量达40TB 1.5PB，带宽负载达到40Gbps 200Gbps，具备130Tbps带宽储备能力。所以我们暂时选择了阿里云的CDN。

我们根据阿里云的CDN文档进行配置之后遇到一个问题，cdn的域名配置成功后，在nginx上找不到文件，直接跑出404的异常。后面通过在 nginx中增加了一个解析cdn域名执行文件的配置 之后文件访问正常。

如果文件数量不算特别多，访问量不算特别大，可以通过配置本地nginx即可解决部分宽带压力，毕竟这个是不用花钱的。如果访问量下不了，而且宽带压力较大，则直接推荐使用阿里云的CDN服务，配置各种都挺简单。我们的服务器是托管在电信机房，百兆共享宽带，在没有使用CDN之前，每天8:00-00:00这个时间段基本上服务器网络下行速度11M/s，配置CDN之后基本在1-5m/s之间浮动。所以说使用CDN还是能解决一大部分问题。

渴望加载生成较慢的查询

【中文标题】渴望加载生成较慢的查询

【英文标题】：Eager loading generating slower queries

【发布时间】：2011-07-20 03:40:48

【问题描述】：

我正在优化我的应用程序并注意到一些有趣的事情。我最初在我的控制器中有这个语句

@votes = Vote.paginate(:page => params[:page], :order=>"created_at DESC")

这在我看来

<% @votes.each do |vote| %>
<tr>
  <td><%= vote.user.display_name %></td>
...

我尝试将控制器更改为使用预加载：

@votes = Vote.includes(:user).paginate(:page => params[:page],
  :order=>"created_at DESC")

这样做时，我注意到加载投票/索引的 ActiveRecord 查询时间从 180 毫秒增加到 440 毫秒。通过预先加载成功地减少了查询的数量。但是，我发现这是一个在急切负载情况下的耗时查询仅：

  SQL (306.5ms)  SELECT COUNT(DISTINCT "votes"."id") FROM "votes" LEFT OUTER JOIN "users" ON "users"."id" = "votes"."user_id"

为什么我的代码要求对左外连接进行计数？它在非急切负载情况下不存在。在非急切负载情况下，这是我能找到的最接近的语句：

  SQL (30.5ms)  SELECT COUNT(*) FROM "votes"

这与分页有关吗？是两者的结合吗？

【问题讨论】：

我今天也遇到了这个问题。我正在对一个 habtm 关联进行包含，它最终生成了一个包含模型的每个唯一 ID 的查询。这是all that i found on the issue

如果您将此作为答案发布，您将获得我的赞誉积分 =P 我认为您的问题将通过以下 Malte 的解决方案得到解决

【参考方案1】：

是的，该查询似乎是由分页插件生成的。此查询对于估计总页数是必要的。

但如果您知道记录的数量（之前通过简单的SELECT COUNT(*) FROM "votes"），您可以使用:total_entries 选项将该数字传递给 will_paginate！

（有关详细信息，请参阅WillPaginate::Finder::ClassMethods。）

顺便说一句，您是否为votes.user_id 创建了索引？可能是减慢了查询速度。我想知道为什么 DISTINCT 子句会占用这么多时间，因为 id 可能已经有一个唯一的约束（如果没有，请尝试添加一个）。

【讨论】：

是的！这消除了那个 SQL 请求！谢谢！我只是使用了c = Vote.count 和@votes = Vote.includes(:user).paginate(:page => params[:page], :order=>"created_at DESC", :total_entries => c)

回答您的问题，是的，我在votes.user_id 上有一个索引。我认为查询花费这么长时间的原因是它正在执行外部连接？我仍然很困惑为什么我在使用includes 时会从 will_paginate 得到这个查询，但不是没有。