タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
先日、某所のnginxを1.14系から1.16系に更新したところ、レスポンスタイムが悪化する現象に遭遇したので、その時の対処記録。以下は99percentileと95percentileでのレイテンシのグラフ。 99percentile latency 95percentile latency nginxのバージョンアップでレスポンスタイムが悪化するのを経験したのは初めてのことだったのですが、いろいろ調べてみるとアップストリームサーバとのキープアライブに関する挙動が大きく変わったのが原因で、そのへんのディレクティブの値をちょいと調整することで元のレスポンスタイムを維持できるようになりました。 nginxの1.16系と1.14系の大きな違いの一つとしてkeepalive_requestsディレクティブが従来のhttp, server, locationコンテキストに加えてupstreamコン
概要 gRPCでは１つのHTTP/2コネクション上でstreamを多重化します。 しかしidleなコネクションは、LBなど間に介在するネットワーク機器によって気づいたら切断されているケースがあります。 そうならないよう、定期的にパケット（PINGフレーム）を流して「idleではないよ」とコネクションを維持しようとするのがいわゆるkeepaliveという仕組みです。 gRPCではデフォルトの設定では無効になっている＆地味に設定が細かいので１つ１つ説明します。 gRPCのkeepaliveの役割 大きく２つあります。 １つ目は先に述べたようにidleコネクションを維持するためです。 ２つ目は死んだコネクション（TCPハーフオープン）があったら切断し、再接続するためです。 例えばNLBでは350秒以上idleなコネクションが切断される仕組みがあり、これによって普段あんまりトラフィックの無いサービ
HTTP KeepAliveとリバースプロキシにまつわる話 | TECHSCORE BLOG | TECHSCORE BLOG
WEBアプリケーションサーバを構築する際、ELBやApacheやnginxなど何らかのリバースプロキシを前段に置くケースは非常に多いと思います。 今回は、筆者が各種リバースプロキシで1回ずつ位ハマった気がする、KeepAliveタイムアウト問題について解説します。 まずはHTTPにおけるKeepAliveについて簡単に説明します。 HTTP1.1の持続的接続(Persistent Connections)の根幹をなす機能で、1つのTCPコネクションで複数のリクエスト、レスポンスをやり取りする仕組みです。 このような機能が求められた背景には、TCP接続時の3Wayハンドシェイクのような負荷の高い処理を減らしたい、という目的があります。 単純化したシーケンス図で表すと、以下のようなフローになります。 KeepAliveタイムアウト サーバー側は次のリクエストを待つ際、いつ送られるかわからないリ
背景 以前gRPCのkeepaliveについて説明しました。 christina04.hatenablog.com keepaliveの目的は idleコネクションを維持するため 死んだコネクション（TCPハーフオープン）があったら切断し、再接続するため と書きましたが、どちらの検証もアクティブなRPCがなくなってからのkeepaliveの例であり、リクエストが続く中での挙動は検証できてなかったので今回はそれを行います。 環境 grpc-go v1.38.1 Ubuntu 18.04 (Linux Kernel 4.15.0-147-generic) PINGフレームはいつ送信される？ Client-side keepaliveのパラメータであるTimeで送信間隔は設定できますが、いつ条件を満たして発火する(タイマーが開始する)かについては説明していませんでした。 Proposalでは i
bgamari - 2021-06-08 In GHC 9.0 we have reworked the primops used for guaranteeing heap object lifetime in the presence of off-heap references. The result is a new primop, keepAlive#, which largely replaces the venerable touch# operation. This post will give some background on touch#, describe the rationale for this change, discuss some of the alternatives that were evaluated on the way to this ne
# TL;DR Linux は TCP KeepAlive に対応していますが、普通に socket を開くだけだと有効化されません。既定では無効の状態です。アプリケーションが setsockopt システムコールを (第 3 引数 = 1 で) 呼び出して、初めて TCP KeepAlive が有効化されます (ちなみに既定で TCP KeepAlive が無効なのは、Windows でも同様です)。 アプリケーションで TCP KeepAlive を有効化するには、2 つの方法がとれます。 アプリケーションで setsockopt を実装する。ただし、ソースコードの編集やコンパイル/ビルドが出来る必要があります。 LD_PRELOAD=libkeepalive.so を環境変数に宣言してからアプリケーションを実行する。ソースコードに手を加えなくて良いのが利点である一方、libkeepa
Advent Calendar 2020 全部オレシリーズ 14日目です。誕生日記念号です。おめでとうございます。ありがとうございます。 先日も gRPC と NLB での idle timeout の問題について触れましたが、今回は Istio の Ingress Gateway で NLB の idle timeout に対応する方法です。 Go言語ではクライアント側もサーバー側もデフォルトで15秒間隔の TCP keepalive が有効になるということも書きましたが、Istio を導入した環境では、サーバーの接続相手は localhost の Envoy (istio-proxy) となるため、TCP keepalive もその間で閉じてしまってクライアントには届きません。クライアントと TCP 接続するのは Istio Ingress Gateway なのです。 また、クライアン
Application Load Balancer enables configuring HTTP client keepalive duration
Application Load Balancer (ALB) now provides flexibility that allows you to configure HTTP client keepalive duration for communication between clients and load balancer. With this feature, you can configure keepalive values to optimize client experience. The HTTP client keepalive duration value specifies the maximum amount of time that ALB will maintain an HTTP connection with a client before clos
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
keepalive_requests in upstream context - Qiita
gRPCのkeepaliveで気をつけること - Carpe Diem
【図解】初心者に分かりやすいIPsecの仕組みとシーケンス～パケットフォーマット,DPD(keepalive)について～
gRPCのkeepaliveで気をつけること その２ - Carpe Diem
The tale of keepAlive# — The Glasgow Haskell Compiler
Linux での TCP KeepAlive 有効化方法 | /etc/openjny
Istio で Downstream への TCP keepalive を送る方法
全稼働の9割をテレワーク化、「自宅内通信費」は全額補助！ ワーケーションにも挑戦中 ～ 西田陽介（KeepAlive株式会社 代表取締役）のテレワークスタイル【みんなの在宅ワーク：第46回】
「Node.js 19」がリリース ～HTTP(S)/1.1 KeepAliveが既定で有効化／「Active LTS」は今月下旬に「Node.js 16」から「Node.js 18」へ
mineosim.com
grandfleet.info
applech2.com
www.watch.impress.co.jp
news.yahoo.co.jp
news.yahoo.co.jp