2

現在、Heroku でホストされている ruby​​ on rails アプリを持っており、New Relic で監視しています。私のアプリは使用時に多少ラグがあり、New Relic モニターには次のように表示されます。

NewRelicGraph

大部分の時間がリクエスト キューイングに費やされていることを考えると、これは、追加のワーカー dyno を使用した場合、アプリのスケーリングが向上することを意味しますか? それとも、コードを最適化することで修正できるものですか? これがばかげた質問である場合は申し訳ありませんが、私は完全な初心者であり、すべての助けに感謝します. ありがとう！

==編集==

追加のムーラを砲撃する前に、私がこれについて明確であることを確認したかっただけです. そのため、New Relic は、ここで確認できるように、ブラウザー側で次の統計情報も提供してくれました。

NewRelicBrowserGraph

このグラフは、ユーザーが費やした時間の大部分が Web アプリケーションの待機に費やされていることを示しています。これは、アプリが要求キューでほとんどの時間を費やしているという事実に起因すると考えられますか? 言い換えれば、エンド ユーザーが経験している 1.3 秒の応答時間は、現在、コードの最適化だけではほとんど短縮できないということですか? （基本的には、お金を使う必要があるかどうかを尋ねています）ありがとうございます！

4

2 に答える 2

3

リクエスト キューイングとは、基本的に「ウェブ インスタンスがリクエストを処理できるようになるのを待つ」ことを意味します。

したがって、応答時間をある程度短縮する最も簡単で最速の方法は、Web インスタンスの数を増やして、アプリがより多くのリクエストをより高速に処理できるようにすることです。

アプリケーションが 1 分あたりにより多くのリクエストを処理できるようになるまで、個々のリクエストを高速化するようにコードを最適化することは可能かもしれません。これにより、キューからのリクエストがより迅速に取り出され、全体的なリクエスト キューイングの問題が軽減されます。

いずれにせよ、とにかくコードを最適化するためにできる限りのことをするのは良い考えです。しかし、まずワーカーを追加すると、リクエストのキューイングの問題が軽減または解消される可能性が高くなります。

編集

あなたの追加情報で、一般的には話は同じだと思いますが、お金を使う前に深い理解を得ることは素晴らしい仕事です.

  1. リクエスト キューイングがあるのは、ウェブ インスタンスがリクエストを処理できるようになるのをリクエストが待っているためです。Web インスタンスを追加すると、使用可能なインスタンスが増えるため、これに直接影響します。

  2. アプリを最適化することで、各リクエストの処理時間を大幅に短縮できる可能性があります。これが発生した場合、リクエストが処理されるまでの待機時間を短縮することで、リクエストのキューイングも削減されます。

待ち行列の問題にすぐに対処するために、今のところユーザーにより多くのWeb インスタンスを提供してから、コードをできる限り最適化することをお勧めします (これが最優先事項であると仮定します)。また、アプリの応答速度に関係なく、ユーザーが増えた場合は、対応するためにさらに多くの Web インスタンスを実装する必要があります。ユーザーも増えているため、これは良い問題です。

頑張ってください！

于 2012-06-29T04:29:37.567 に答える
1

この特定の質問は答えられているように見えますが、これを投げ入れたいだけです。New Relic と Engine Yard の関係者による次のブログ記事を見つけました: Blog Post。

ここで注意したいのは、New Relic のリクエスト キューイングは、実際にキューに並んでいて処理できないリクエストであるとは限らないということです。New Relic がこのメトリクスを計算する方法により、基本的には nginx によってヘッダーに設定されたタイムスタンプを読み取り、Time.nowNew Relic メソッドがそれを取得した時点からそれを差し引きます。ただし、New Relic は、コードのいずれかのフックが呼び出された後に実行されます。before_filterしたがって、これらの s で大量の計算集約型またはデータベース集約型のコードが実行されbefore_filterている場合、実際に表示されているのはキューイングではなく、リクエストのレイテンシーである可能性があります。

実際にキューを調べて、そこに何があるかを確認できます。Passenger を使用している場合、これは非常に簡単passenger statusです。コマンド ラインに入力するだけです。これにより、キューに入っているリクエストの数など、各 Passenger ワーカーに関する大量の情報が表示されます。を前に を付けて実行するとwatch、コマンドは 2 秒ごとに実行されるため、時間の経過とともにキューがどのように変化するかを確認できます (つまり、 を実行するだけwatch passenger statusです)。

Unicorn サーバーの場合は少し難しくなりますが、実行できる ruby​​ スクリプトがここから入手できます。このスクリプトは実際に、ワーカーが取得するのを待っているユニコーン ソケットにあるリクエストの数を調べます。ソケット自体を調べているため、このコマンドを 3 秒ほど頻繁に実行しないでください。GitHub の例では 10 を使用しています。

キューに入れられたリクエストの数が多い場合は、(Heroku でより多くの Web ワーカーを介して) 水平方向のスケーリングを追加することがおそらく適切な手段です。ただし、キューが少ないにもかかわらず、New Relic がリクエストのキューイングが高いと報告している場合、実際に表示されているのはリクエストのレイテンシですbefore_filter。これらのフィルターが実行しているコードを最適化します。

これが、将来このスレッドに来る人に役立つことを願っています！

于 2014-04-30T16:35:53.023 に答える