AWS ELBの504ステータスのGateway Timeoutと格闘した話(最終的にALBで直った） - YOMON8.NET
ELBのメトリクスのステータスには、バックエンドのEC2が返したステータス(HTTPCode_Backend_XXX)と、ELB自身のステータス(HTTPCode_ELB_5XX)があります。 ELB自身のステータスコードの中には504というエラーコードがあります。この504エラーと格闘した話を書きます。 この504エラーは、CloudWatchのメトリクスで言うとHTTPCode_ELB_5XXに上がってきます。 このメトリクスは5XXという名前の通り、504以外のコードも含んでいます。 例えば、 HTTP 502: Bad Gateway (バックエンドサーバからのレスポンスがHTTPレスポンスとして解釈不能)や、 HTTP 503: Service Unavailable (突発的なアクセス増によりスケールが間に合わない時など） などがあります。 実際に504かどうかはS3に保存され
nginxのproxy_read_timeoutはupstreamにも注意 - noob
proxy_read_timeoutが思ったような挙動ではなかったので実験してみた． 想定していた挙動 こんな設定のnginxに対して upstream server_pool_a { server web001:80 max_fails=3 fail_timeout=30s; server web002:80 max_fails=3 fail_timeout=30s; } proxy_read_timeout 60 無限ループするようなCGIをプロキシさせたら web001にリクエスト ↓ 60秒以内にレスポンスが完了しない ↓ 504 Gateway Time-out 発生 となると思っていた． 実際の挙動 ところが実際には以下のような挙動だった． web001にリクエスト ↓ 60秒以内にレスポンスが完了しない ↓ web002にリクエスト ↓ 60秒以内にレスポンスが完了しない ↓
名前解決のタイムアウト設定 - 揮発性のメモ２
resolv.confにオプションが書けることが判明 timeout:n 「レゾルバが他のネームサーバで問い合わせをリトライする前に、 リモートネームサーバからの応答を待つ時間」を設定する。 単位は秒で、デフォルトは RES_TIMEOUT である (現状では 5 秒、 を参照)。 attempts:n 「レゾルバが諦めて呼び出し元のアプリケーションにエラーを返すまでに、 ネームサーバに問い合わせを行う回数」を設定する。 デフォルトは RES_DFLRETRY 回である (現状では 2 回、 を参照)。 Man page of RESOLV.CONF つまり、タイムアウト時間×リトライ回数 という式になるのでデフォルトは5×2＝10秒が最大待ち時間 $ time ping uuu.com ping: unknown host uuu.com real 0m10.029s user 0m0.
Amazon ELB を使うときは、KeepAlive On & Timeout 120 - kunihikokido
ELB を使うときは、KeepAlive On & Timeout 120 以下のブラウザ毎のタイムアウトを見ると、クライアントがずっとコネクションを維持し続ける傾向にあるため、Webサイトに置けるKeepaliveの設定は無効にし、Timeoutは短くすると言う設定が一般的。しかし、ELBは単にTCPをリレーするだけではなく、バックエンドインスタンスとの間で無通信でも60秒はセッションを維持するため、状況が異なる。 Opera 11.11 – 120 secondsChrome 13 – at least 300 seconds (server closed after 300 second timeout)IE 9 – 60 seconds (changeable in the registry, appears to apply to IE 8/9 as well though th
DMM inside
なぜDMMがweb3に参入したのか。Seamoon Protocolが目指す新たなエンタメ体験の未来とは
Linux：OSのtcpタイムアウトのデフォルト値について - HiiHahWIKI - making some notes for... -
Linux：OSのtcpタイムアウトのデフォルト値について † 例えば、curlを使用して、タイムアウト値を300秒に指定し、タイムアウトさせるよう無いことをしても、実際180秒を超えたくらいでタイムアウトする事象が発生していました。 これが、curlだけじゃなくて、例えばapacheのmod_proxy_balancerのバックエンドサーバへのタイムアウトについても、タイムアウト値を300秒とかでせっていしても、実際は180秒ちょいでタイムアウトしてしまっていました。 これについて、ちょっと調べたところどうもLinuxのOSとして持っているTCPのタイムアウト値が効いているようだ、ということがわかりました。 ここを見ると分かります。 #cat /proc/sys/net/ipv4/tcp_syn_retries 5 これはtcpのsynを送信するリトライ回数みたいで、以下のロジックでリト
フロント/バックのreverse proxy構成で、指定秒数以内に必ずレスポンスを返す方法 - （ひ）メモ
目的 フロントがHTTPリクエストを受けて、バックエンドのアプリケーションサーバにreverse proxyするような構成において、指定秒数以内に何かしらのレスポンスを返したい。 200が返せない場合は、処理を打ち切って500を返したい。 背景 フロントでApacheやNginxをreverse proxyとして使っている場合、バックエンドが無応答になってしまうと、クライアントにレスポンスが返るのはデフォルトで数十〜数百秒後(ApacheのTimeoutのデフォルトは300秒、Nginxのproxy_read_timeoutのデフォルトは60秒)になってしまいます。 通常のWebサービスではこのオーダーのタイムアウトでもいいのかもしれませんが、数秒以内に(エラーでもいいので)レスポンスを返すことが求められる環境も存在します。(最近、特に多いのではないでしょうか:P) もちろんバックエンドが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://github.com/hiboma/hiboma/blob/master/%E5%90%84%E7%A8%AE%E3%83%84%E3%83%BC%E3%83%AB%E3%81%AE%E3%82%BF%E3%82%A4%E3%83%A0%E3%82%A2%E3%82%A6%E3%83%88%E5%AE%9F%E8%A3%85%E3%81%BE%E3%81%A8%E3%82%81.md
宁波逼拘旅行社
Redis on EC2
Connection keep-alive timeouts for popular browsers
conma.me
cron でうごかしているコマンドをタイムアウトさせる - tokuhirom's blog
cloudpackブログ - ELBのヘルスチェックで指定できる最大値と最小値