状況を簡単に説明します。ダウンロードプロセス中に、静的（css、js、フォント、画像）をダウンロードするために100を少し超えるリクエストが行われる、かなり長い1ページのサイトがあります。 このサイトは、Ruby on Rails 4.1.12をWebサーバーとして使用して作成されました-puma-2.15.3、nginxは静的で、pumaを確認します。 これはすべて、フランクフルト1の場所にあるデジタルオーシャンドロップで開始されます。また、このような初期データがあるため、static.comのようなドメインからasset％{i} .example.comのようなドメインに静的リクエストを転送する必要があります。
まず最初に、これらのアドレスからの静的な戻り値を設定する必要があります。 これを行うには、適切なDNSレコードを構成し（* .example.comのレコードがあり、私の場合はそれで十分でした）、nginx設定を変更します（server_nameディレクティブには、assets0.example形式の通常のキャッチホストがあります） .comとasset0.example.ru。私の場合、このサイトには2つの異なるアドレスからアクセスできます。
server { listen 80; server_name ~^assets\d\.(example\.com|example\.ru)$; root /home/deployer/sites/example/current/public; location ~ ^/assets/ { expires 1m; add_header Cache-Control public,max-age=259200; break; } }
次に、アプリケーション側で静的パスの生成を変更する必要があります。 レールでは、これは基本です：config / production.rbに行を追加するだけです
config.action_controller.asset_host = "assets%d.example.com"
次に、アドレス生成中のレールは、ホスト「assets0.example.com」、...、「assets3.example.com」を交互に使用します。 ちなみに、118個ではなく、正確に4個のアドレス（各リクエストに1個であるため、完全にまっすぐな平行-平行）なのかと思いました。 最初に、追加のホストごとにDNSルックアップが実行され、ページに非常に多くのホストを配置すると、ロードが遅くなります。 第二に、ブラウザは、1つのホストへの同時リクエストの数の制限に加えて、同時リクエストの合計数に制限があります（投稿の最後に制限の具体的な値を示します）。
レールの魔法はもちろん優れていますが、私の場合、異なるドメインからサイトにアクセスするときに異なるアドレスを生成する必要があるため、うまくいきません。 ただし、設定はそれほど複雑ではありません。 また、アプリケーションコードを変更することなく、サイト上のドメインシャーディングをオプションで有効/無効にする機能を設定することにしました。 これを行う最も簡単な方法は、環境変数を使用することでした：
if ENV['DOMAIN_SHARDING'] == 'enabled' config.action_controller.asset_host = Proc.new { |source, request| if request "assets#{source.hash % 4}.#{request.host_with_port}" end } end
ドメインシーケンス番号の決定はこのようになり（source.hash％4）、各ファイルのページがリロードされたとき（まあ、またはサーバーキャッシュがリセットされたとき）、リンクは変更されません。 これにより、ブラウザキャッシュをより効率的に使用できます。 また、リクエストの存在の確認が必要な理由も謎のままですが、ドックに正確に記述されており、さらに深く掘り下げることはしませんでした。
走る
そしてそれは動作します！ まあ、ほとんど。 フォントが壊れ、ブラウザコンソールでCross-Origin Resource sharing policyについて苦情が寄せられました。$ DOMAIN_SHARDING=enabled rails s -e production
メッセージ本文
オリジン 'http：//assets1.localhost：3000'からのフォントは、クロスオリジンリソース共有ポリシーによってロードがブロックされています：要求されたリソースに 'Access-Control-Allow-Origin'ヘッダーがありません。 したがって、Origin 'http：// localhost：3000'はアクセスを許可されていません。
すべてがすぐに使えるとは限らないという悲しい思いを抱いて、彼は反射的に登って「クロスオリジンリソース共有ポリシーレールフォント」について学びました。 font_assets gemの言及を見て、READMEで「フォントアセットのAccess-Control-Allow-Origin応答ヘッダーを設定する」という行を見つけて、これが必要なものだと判断しました。
私の間違いは、あなたが最初に考えなければならなかったことです。 それから私はすぐに、バトルサーバー上の残りの静的要素と同様に、宝石を知らないnginxによって与えられるフォントであることを理解します。 実際、小さなクエストが登場しました。font_assetsを接続した後、すべてが壊れました。 それが壊れた理由を見つけ、ソースを修正し、動作しました; フォークを作成し、Gemfileに登録しました。 本番環境の更新バージョン。 最初に考える必要があることに気づきました。 バージョンをロールバックし、フォークを削除しました。
実際、本番環境の状況を修正するのは簡単でした。ロケーションセクションを少し編集するだけで問題が解決します。
location ~ ^/assets/ { expires 1m; add_header Cache-Control public,max-age=259200; add_header Access-Control-Allow-Origin *; add_header Access-Control-Allow-Methods GET; break; }
一般に、セットアップ自体が終了し、測定を開始しました。
測定結果
クロムインスペクターで[ネットワーク]タブを開き、 ドメイン：*。Example.com / domain：example.comをフィルターに設定して、ページを更新します。 最もハイテクな方法ではありませんが、ダウンロード時間だけでなく、その性質も追跡できます。 （スクリーンショットはグラフの下部のみを示しています）。
キャッシングを有効にすると、シャーディングなし
| キャッシュを有効にし、シャーディングを使用する
|
|
キャッシュを無効にすると、シャーディングなし 
|
キャッシュを無効にし、シャーディングを使用する 
|
|
キャッシングを有効にして、シャーディングなし、Firefox 
|
キャッシュを有効にし、シャーディングを使用して、Firefox 
|
キャッシュをオンにすると、合計時間は平均値を大幅に上回りましたが、通常、ドメインシャーディングのロードでは約0.2〜0.4秒速くなりました。 FFでは、ダウンロードの終わりはほぼ同じでしたが、シャーディングを有効にすると、ほとんどのファイルが以前に利用可能になりました。 また、グラフは、同時接続の数に関するブラウザーの制限を明確に示しています。1つのホストに対して最大6、一般に最大10です。
キャッシュを無効にすると、画像は滑らかになりましたが、シャーディングでは少し速くなりました。 理由はよくわかりませんでしたが、シャーディングなしで速度制限を750 kB / sまでオンにすると、少し速くなりました。
要約すると 、一般的に、ブラウザーが2つの同時接続しか許可していない当時、ドメインシャーディングは状況をさらに改善しましたが、現在ではその使用が理にかなっています。