2016-02-20 33 views
7

ssl経由で何らかの要求を行う場合、数日間、ELBに非常に長い初期接続時間(15秒〜1.3分)が表示されることがよくあります。 奇妙なことに、私はGoogle Chrome(Safari、Firefox、カールではない)でしかこれを観察できませんでした。AWS Elastic Load Balancing:極端に長い初期接続時間を参照

1回限りのリクエストではなく、リクエストの約50%が発生します。これは最初の要求(OPTIONS-call)で発生します。

設定は次のとおりです。 node.jsバックエンド(現在はeu-west-1の2つのAZ)に接続するクロスゾーンELB。すべてのインスタンスは正常であり、要求が処理されると正常に処理されます。現在、システムには基本的に負荷はありません。 ELBのCloudwatchは、バックエンド接続エラー、SurgeQueue(値0)、スピルオーバ数のいずれも報告しません。 ELBメトリックは低い待ち時間(< 100ms)を示します。 私たちはRoute53をELBにルーティングするように設定しました(dnsの問題はありません。添付のスクリーンショットを参照)。

私たちは、すべてこのセットアップを持つ異なるREST-APIを持っています。それはすべてのELBに発生します(それぞれが無意味なノードに接続しています.jsバックエンド)。これらのELBはすべて、雲のテンプレートを使用して同じ方法で設定されます。

ELBは私たちのSSL終了も行います。

何がこのような現象につながる可能性がありますか? ELBが正しく構成されていない可能性はありますか?なぜGoogle Chromeにしか表示されないのでしょうか?

request timing

+0

考え[重複](http://stackoverflow.com/questions/29125264/chrome-slow-initial-connection-to-ec2)。 – gboda

+0

ブラウザでマシンにwiresharkをインストールし、tcpハンドシェイクのどの時点で待ち時間が現れているのかを確認してください。これは非常に珍しいようです。 –

+0

@gboda good find、pity答えもありません。たぶんここに別の場所があるかもしれません。 –

答えて

1

これはアマゾンのエルフに問題があります。 elbはリクエスト数でインスタンス数をスケーリングします。 これらの時間にいくつかのリクエストが表示されるはずです。 Amazonは負荷に合わせていくつかのインスタンスを追加します。 クライアントは起動プロセス中に到達可能になり、クライアントはタイムアウトを取得します。あなたがする必要がありますので、それは完全にランダムです:すべてのIPを取得するために、ELBは、すべてのIP上

  • 使用mtr

  • はCloudWatchの

  • に目が離せないた使用

    • ピング

      手がかりを探す

  • 3

    @Nikita Ogurtsovの優れた答えをフォローアップするだけです。私は私のサブネットのうちの1つだけであることを除いて同じ問題を抱えていたプライベートと残りの公開された。

    はあなたのサブネットが公共のだと思う場合でも、私はあなたが彼らすべてゲートウェイを持っていることを保証するために、ルートテーブルをダブルチェックをお勧めします。

    あなたはすべてのあなたのLBのサブネットのゲートウェイを持つ単一のルートテーブルを使用することができる場合は、このメイクセンス

    VPC/Subnets/(select subnet)/Route Table/Edit

    0

    ソリューションあなたはDNSがELBに直接ヒットするように設定されている場合 - >あなたにアソシエーション(IP、DNS)のTTLを削減する必要があります。あなたのトラフィックに重大な損害を与える可能性があるので、IPはいつでもELBで変更することができます。

    クライアントは、ELBからのいくつかのIPをキャッシュに保持しているので、問題が発生する可能性があります。あなたは弾性ロードバランサを作成したら、あなたのEC2インスタンスへの着信トラフィックとルート要求を受け入れるように、それを構成する必要があります

    スケーリング弾性ロードバランサ。これらの構成パラメータはコントローラによって格納され、コントローラはすべてのロードバランサが正しい構成で動作していることを保証します。コントローラはまた、ロードバランサを監視し、クライアント要求を処理するために使用される容量を管理する。これは、より大きなリソース(より高いパフォーマンス特性を持つリソース)またはより多くの個別のリソースのいずれかを利用することによって容量を増加させます。 Elastic Load Balancingサービスは、ロードバランサのDNS(Domain Name System)レコードが拡張されたときに更新し、新しいリソースがそれぞれのIPアドレスをDNSに登録するようにします。作成されるDNSレコードには、60秒のTTL(Time-to-Live)設定が含まれています。クライアントは少なくとも60秒ごとにDNSを再ルックアップすることが予想されます。デフォルトでは、クライアントがDNS解決を実行するときにElastic Load Balancingは複数のIPアドレスを返し、各DNS解決要求でレコードがランダムに並べ替えられます。トラフィックプロファイルが変更されると、コントローラサービスはロードバランサを拡張し、より多くの要求を処理し、すべての可用性ゾーンで同等にスケーリングします。

    Best Practices ELB on AWS

    関連する問題