22

現在、Herokuでホストされているrailsアプリ（rails3.2.8およびruby1.9.3）のパフォーマンスを改善しているところです。この間に、ソースを追跡するのが非常に難しいと思われる1つの憂慮すべき問題に遭遇しました。問題がどのように発生し、どのように問題を切り分けようとしたかについて簡単に説明します。

-

6月頃から、サイト全体でTime toFirstByteで奇妙なラグ動作が発生しています。このサイトを使用すると問題が明らかになり（アプリケーションが10〜20秒間応答しない場合もあります）、webpagetest.orgを介したウォーターフォール分析にも問題があります。私たちはデンマークに拠点を置いていますが、この結果はどのホストからも得られます。

問題を確認するために、ベンチマークテストを実行しました。このテストでは、300個の同一のリクエストを単純なページに送信し、応答時間を測定しました。フロントページに300のリクエストを送信した場合、応答時間の中央値は1秒未満であり、これはかなり良好です。私たちを怖がらせるのは、60件のリクエストがその2倍以上かかり、そのうち40件が4秒以上かかることです。一部のリクエストには16秒ほどかかります。

これらの遅いリクエストはいずれも、パフォーマンスの監視に使用するNewRelicには表示されません。リクエストキューは表示されず、Webプロセスをどれだけ大きくしても結果は同じです。それでも、問題の原因がアプリケーションコードであることを否定できなかったため、ラックミドルウェアを介してリクエストに応答する別の実験を試みました。

このミドルウェア（TestMiddleware）をラックスタックの先頭に配置することで、アプリケーションにヒットする前にリクエストを返し、次のミドルウェアやRailsアプリが遅延を引き起こさないようにしました。

Middleware setup:
$ heroku run rake middleware
use Rack::Cache
use ActionDispatch::Static
use TestMiddleware
use Rack::Rewrite
use Rack::Lock
use Rack::Runtime
use Rack::MethodOverride
use ActionDispatch::RequestId
use Rails::Rack::Logger
use ActionDispatch::ShowExceptions
use ActionDispatch::DebugExceptions
use ActionDispatch::RemoteIp
use Rack::Sendfile
use ActionDispatch::Callbacks
use ActiveRecord::ConnectionAdapters::ConnectionManagement
use ActiveRecord::QueryCache
use ActionDispatch::Cookies
use ActionDispatch::Session::DalliStore
use ActionDispatch::Flash
use ActionDispatch::ParamsParser
use ActionDispatch::Head
use Rack::ConditionalGet
use Rack::ETag
use ActionDispatch::BestStandardsSupport
use NewRelic::Rack::BrowserMonitoring
use Rack::RailsExceptional
use OmniAuth::Builder
run AU::Application.routes

次に、同じスクリプトを実行して応答時間を文書化し、ほぼ同じ結果を得ました。応答時間の中央値は約130ミリ秒でした（アプリにヒットしないため、明らかに高速です。ただし、60リクエストは400ミリ秒以上、25リクエストは1秒以上かかりました。また、一部のリクエストは16秒ほど遅くなりました。

1つの説明は、ネットワークまたはDNSセットアップの低速ホップに関連している可能性がありますが、tracerouteの結果は完全に問題ないように見えます。

この結果は、Herokuでホストされている別のrails3.2およびruby1.9.3アプリケーションで応答スクリプトを実行したことで確認されました。奇妙な動作はまったくありません。

DNSの設定は、Herokuの推奨事項に従います。

-

控えめに言っても混乱しています。Herokuのルーティングネットワークに何か怪しいものはありますか？なぜ私たちはこの奇妙な行動を見ているのですか？どうすればそれを取り除くことができますか？そして、なぜNew Relicでそれを見ることができないのですか？

4

2 に答える 2

24

それは一種のリクエストキューイングであることが判明しました。時々、そのWebサーバーはビジーで、herokuはランダムに着信するリクエストを任意のdynoにランダムにルーティングするため、データベースの問題などが原因で完全にスタックしたdynoの後ろのキューに入る可能性があります。奇妙なことに、これはNew Relicではほとんど目立たなかった（チャートでシンを表示するときに他のすべてのリソースのチェックを外すと、キューが突然表示されるのは良い考えです）

2013年2月1日編集： Newrelicでほとんど目立たなかった理由は、測定されなかったことが判明しました。http://rapgenius.com/Lemon-money-trees-rap-genius-response-to-heroku-lyrics

これは非常に苛立たしいことであり、Herokuを離れて専用サーバーを採用することになりました。これにより、1/10のコストで20倍のパフォーマンスが得られました。さらに、これが起こったときに、私たちがそれを疑って何度も強調したにもかかわらず、速度が遅いのは彼らのインフラストラクチャによるものであると否定したHerokuに失望していると言わなければなりません。私たちはこのような答えさえも得ました：

Heroku 28/8 2012：「NewRelicでリクエストのキューイングやその他の速度低下が報告されていない場合、これはサーバー側の問題ではない可能性があります。Herokuの内部ルーティングには1ミリ秒未満かかるはずです。監視システムのいずれも、現在、ルーティングの問題があります。」

さらに、彼ら自身がHerokuと非常に緊密な仕事上の関係を持っているにもかかわらず、この問題に気付いていないように見えるNewrelicと話をしました。

Newrelic 29/8 2012：「これを引き起こしている原因はRubyエージェントの可視性が始まる前に発生しているようです。エージェントが記録するキュー時間は、リクエストがdynoに入ったときからであるため、それ以前にスローダウンが発生しています。」

結論としては、実際にはボトルネックではなかったコードの最適化に何時間も費やすことになりました。さらに、パフォーマンスを向上させるために必死に高すぎるdynoスケールで実行しましたが、これから実際に得られたのは、HerokuとNewrelicの両方からのより大きなレシートでした-クールではありません。変わってよかったです。

PS。当時、私たち（Newrelics自身のアドバイスによると）がバックグラウンドワーカープロセスの監視を無効にしていたにもかかわらず、newrelicproがすべてのdynoに課金されるバグさえありました。両者が間違いを認めるまでには、多くの時間と多くの電子メールが必要でした。

PPS。現在進行中のディスカッションに気付いていない場合は、ここにリンクhttp://rapgenius.com/James-somers-herokus-ugly-secret-lyricsがあります。

編集26/22013Herokuはニュースレターで、NewrelicがHerokuの状況に光を当てるはずのアップデートをリリースしたと 発表しました。

2013年8月4日編集 Herokuがこのト​​ピックに関するFAQをリリースしました

于 2012-10-31T09:09:11.190 に答える
0

tracerouteは、ネットワークの問題を適切に測定するものではなく、ネットワークに沿った障害を検出できるツールですが、最良のビューを表示することはできません。

静的なWebページを作成し、WebページテスターからのIPアドレスでヒットしてみてください。それでも遅い場合は、ネットワークのせいにします。

何らかの理由で高速である場合は、別の問題があります。

于 2012-10-28T23:15:49.237 に答える