0

Rails 3.2 アプリケーションの開発を引き継いでおり、ページの読み込み時間を改善する最善の方法を探しています。サイト自体は、実際の Web アプリケーションというよりは、動的な大規模な Web サイト (サイトはhttp://korduroy.tv/、サーフ ライフスタイル コミュニティ サイト) であり、ユーザーごとに異なるいくつかの小さな部分があります。 、サイトのほとんどは誰にとっても同じ経験です。

ページの読み込み時間はかなり遅く、サーバー ログを見ると、各ページが非常に多くの動的コンテンツを読み込んでいるためと思われます (たとえば、ほとんどのページは 10 以上のモデルからリソースを読み込んでいます)。できることをやり直してリファクタリングしたいと思っていますが、基本的なパフォーマンスの勝利を探しています。サイトの大部分がすべてのユーザーにとって同じであることを知っている場合、コンテンツをサーバーに積極的にキャッシュしたり、何らかのバックグラウンド ジョブによって生成された静的コンテンツを提供したりする方法はありますか?

最初に考えたのは、Jekyl のような静的サイト ジェネレーターを使用するジョブを作成し、基本的にサイトの静的コピーを作成し、それを cdn で提供できるようにすることでした。私の直感は、これはおそらくそれを行う方法ではないと言っています。さらに、動的に提供する必要があるページ (ユーザー プロファイル ページなど) がいくつかあります。

どんな推奨事項も素晴らしいでしょう。免責事項、私はフロントエンドの分野から来ており、サーバー側の最適化に関するベストプラクティスについてほとんど知識がありません. ありがとう！

4

1 に答える 1

1

あなたが書いたことから、あなたの最大の利益は、memcache ストアを使用してフラグメント キャッシュを実装することになると思います。Rails キャッシングに関する決定的なガイドとして、 http: //guides.rubyonrails.org/caching_with_rails.htmlを参照してください。

ユーザーに依存しない一部のコンテンツ (ホームページなど) については、ページ キャッシュまたはアクション キャッシュを使用することで解決できるかもしれませんが、1 日に何百万ものリクエストを処理している場合を除き、そうではありません。確かにこれは必要です。

javascript と css は rails アセット パイプラインに従ってコンパイルされているように見えますが、イメージには sha1 ハッシュが欠落していて、リソースの積極的なブラウザー キャッシュを許可していることに気付きました (内容が変更されることを心配する必要がないため)。画像を変更すると新しいハッシュが取得されます)。ここで重要なのは、アセット パイプラインを有効にし、デプロイ ( rake assets:precompile) の一部としてアセットをコンパイルし、image_tagandasset_pathヘルパー (またはimage-urlsass ヘルパー) を使用することです。また、ページを更新しているときに、nginx がコード 304 (変更されていない) でブラウザーに応答していることを確認してください。これは Rails サーバーの負荷には影響しません (同じサーバーで nginx と rails の両方を実行している場合を除きます) が、ページの平均読み込み時間は短縮されます。

SQL クエリのキャッシュやこれらの最適化などのより高度な手法を検討できますが、これにより複雑さが増し、コードベースの維持が難しくなる可能性があります。最初にビューのキャッシュを試して、読み込み時間が許容レベルになるかどうかを確認してください。

于 2012-07-30T08:28:05.947 に答える