Part 2: Lessons learned tuning TCP and Nginx in EC2 « Chartbeat Engineering Blog
Part 2: Lessons learned tuning TCP and Nginx in EC2 February 12th, 2014 by Justin EDIT 2/20/14: Updated to reflect correct response time metric In part 1 of our post, one of the items we discussed was our issues with using DNS as a load balancing solution. To recap, at the end of our last post we were still setup with Dyn’s load balancing solution and our servers were receiving a disproportionate
[Amazon VPC]ハードウェアVPN接続のMTUとTCP MSSの最適値を探す | DevelopersIO
さて、Management Consoleの[VPN Connections]画面から、各機器に合わせた設定ファイルをダウンロード出来ることは上記の記事でご説明しました。 この設定ファイルの内容を見てみると、ちょっと気になる部分があります。例えばGeneric Vendorだと... IPSec ESP (Encapsulating Security Payload) inserts additional headers to transmit packets. These headers require additional space, which reduces the amount of space available to transmit application data. To limit the impact of this behavior, we recommend t
![[Amazon VPC]ハードウェアVPN接続のMTUとTCP MSSの最適値を探す | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/495673edbefe7b7bc5e6e9e54b2565989b893342/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2013%2F09%2Faws1.png)
TCP Fast Open – Webを速くするためにGoogleがやっていること Make the Web Faster 4 –
TCP Fast Open – Webを速くするためにGoogleがやっていること Make the Web Faster 4 – Jxck HTTPは、その下層にあたるトランスポートレイヤーのプロトコルとして、通常TCPを使用します。 したがって、TCPのレイヤで速度が改善することは、そのままWebの高速化につながる可能性があるといえます。 GoogleはWebを速くするための活動として、TCPのようなプロトコルレイヤの改善にも取り組んでいます。 今回はその中の一つ、TCP Fast Openを取り上げ、解説と動作検証、簡単なベンチマークを行います。 検証環境等は最下部に記載します. Make the Web Faster: TCP Fast Open 3 Way Handshake TCPは、「正確、確実にデータを届ける」ことを重視した設計になっています。 特に接続確立時には、双方の状
LinuxのTCP SYNの再送間隔の初期値が3秒から1秒に変更されていた - 元RX-7乗りの適当な日々
ということに、(今更？)気付いたお話です。 HAを組んだ際のVIPの切り替えテストをやっているときに、高負荷時とかは切り替えに7秒ぴったりかかるケースとかがあって、7秒って何の数字だろうと疑問を持ちました。 OSは、CentOS 6.4(2.6.32-358.23.2.el6.x86_64)です。 TCP SYNの再送間隔が、1...2...4...秒になっている で、tcpdumpを眺めていると以下のようなシーケンスです。 11:50:35.689301 IP client-host.8957 > server-host.http: Flags [S], seq 1616681830, win 14600, options [mss 1460,sackOK,TS val 889880946 ecr 0,nop,wscale 7], length 0 11:50:36.688503 IP
TCP 3-way handshakeのレイテンシ軽減のためのTCP_DEFER_ACCEPTソケットオプション - ゆううきブログ
2013/10/22 追記した． Starletのコード読んでてlistening socketにTCP_DEFER_ACCEPTとかいうオプション渡してたので、これ何だって思って調べた． TCPに特に詳しいわけではないので理解に誤りがあるかもしれない． package Starlet::Server; ... # set defer accept if ($^O eq 'linux') { setsockopt($self->{listen_sock}, IPPROTO_TCP, 9, 1) # 9がTCP_DEFER_ACCEPTを表す and $self->{_using_defer_accept} = 1; } ... TCP_DEFER_ACCEPTはLinux 2.4から導入されている． Linux 2.6.32から挙動が若干変わっているらしい． (linux の TCP_DE
TCP Fast Openを試してみる - milieuの日記
kernel3.8がリリースされてついにTCP Fast Openがクライアント、サーバサイド共に実装さた。カーネルのソースを見てみるとやはり結構な変更でpatchで2000行レベルらしく、これ仕事で実装したくないなーというかバグを出す自信があるというのが正直な感想だが、とりあえず動作概要ぐらいは知っておかないとまずいので遊んでみた。TCP Fast Openの認証？部分でAESを使うらしくSandy BridgeならAES-NIを使えばCPU負荷的に問題ないかとか調べたかったが、家で使用しているPCはCPUが残念ながらWestmereなのでそれは諦めた。動かすにあたりFedora18を用意しないと！と思いたちVM環境にインストール。そういえばFedora18がリリースされた当初はVMwareにインストールを試みたが失敗したという苦い記憶が蘇えったが、今回はVirtualboxだったおかげ
TCP/IPの通信の切断検知 - 揮発性のメモ２
プログラムが終了するときはOSがFINとか送ってくれるけど、途中でLANケーブル抜けたときとかはどうにもならないので 自分で切断を検知する必要がある。キープアライブを使って切断を検知する。 int option = 1; setsockopt( sd, SOL_SOCKET, SO_KEEPALIVE, (void*)&option, sizeof(option) ); デフォルトでは切断検知まで 2時間11分15秒。 2時間とか待ってると日が暮れるので、これをせめて3分とかにする int option = 1; setsockopt( sd, SOL_SOCKET, SO_KEEPALIVE, (void*)&option, sizeof(option) ); option = 60; setsockopt( sd, IPPROTO_TCP, TCP_KEEPIDLE, (void*)&
syncookiesとListenバックログとパケットロスト
たまにはLinuxネタを。 Listenバックログは、伝統的なUNIXの実装だと、SYN_RCVDとESTABLISHEDの両方のソケット数を数えますが、LinuxのそれはESTABLISHEDな状態の数だけを数えるようになっています(manを見よ)。 これは何でかというと、いわゆるSYN Flooding攻撃への対応として、Linuxはsyncookieを実装したことの副作用なのだと思います。syncookieを実装していると、SYNに対してSYN_ACK(COOKIE)を返すコストがほぼゼロ（メモリコストとしては）になるので、来たSYNにすべてSYN+ACKを返すことが可能です。 したがって、SYN_RCVDの数は数えても意味がなくなったので、それはListenバックログの数としてカウントしないようにした、ということのようです（厳密に言うと、tcp_max_syn_backlog個まで
Linux SYNパケット取りこぼし - LowPriority
Linuxで負荷も問題になるほど高くなくlisten及びsynのbacklogも溢れてないのに 特定のホストからのみSYNを吸い込んでSYN-ACKを返さない事がある場合があった。 必ず吸い込むというわけではなく、一発で通る場合と数回再送受けてから処理するのも あったりして謎な感じ。tcpdumpで見てもパケット単位の不整合は特に見あたらない。 受け付けている環境で変更されていたTCPパラメータは以下で、syncookies以外は IN/OUTどの部分の処理に関わるのかDocument読んでも良く解らないので、それぞれに ついて参照箇所を調べてみた。(PATHはKERNELのnet/以下) net.ipv4.tcp_tw_reuse (sysctl_tcp_tw_reuse) Outbound Connectionだけ影響 ipv4/tcp_ipv4.c:tcp_v4_connect ip
net.core.somaxconnについて調べてみた - 祈れ、そして働け ～ Ora et labora
概要 ↓ memcachedのtcp_backlogのデフォルト値は1024で、stats settingsにも1024と表示されているのですが、 stats settings ... STAT tcp_backlog 1024 ... END↓ net.core.somaxconnがデフォルト値のままだと128に切り詰められてしまい、 # cat /proc/sys/net/core/somaxconn 128負荷が高いサーバーでは接続要求を取りこぼしてしまうことがあるそうです。 このnet.core.somaxconn、MemcacheやMySQLなど、高負荷時に多くの接続要求を受け付けるサーバーではチューニングが必要なカーネルパラメータのようです。いったいどういう値なのか、調べてみました。 net.core.somaxconnとは TCPソケットはlisten()関数の第二引数 ba
時代遅れひとりFizzBuzz祭り bash編おまけ（TCPクライアント／サーバ版） - 新・日々録 by TRASH BOX@Eel
id:eel3:20111031:1319989854 のおまけ。 bash 2.04以降では/dev/tcpや/dev/udpを使用してネットワーククライアントの処理を記述することができる。これらは実際に/dev以下にデバイスノードが存在する訳ではなく、bash上でのみ有効なシンタックス・シュガーのようだ（つまりOSの機能ではない）。 bashのネットワークサポートはnetcatのようにバックドアとして悪用される可能性がある為、ビルド時に有効／無効を切り替えられるようになっている。ディストリビューションによっては無効になっているようだ。 Ubuntu 10.04 LTSのbash 4.1.5では有効になっているので、試しにTCPクライアントアプリを書いてみた、FizzBuzzで。 #!/bin/bash # fizzbuzz_tcp_client.sh usage() { echo "U
TCPカーネルパラメータによる障害復旧時間の短縮 - GeekFactory
クラスタ構成のサーバでは、障害発生後にクライアントがすぐに復旧しない場合があります。サーバ側がフェイルオーバした後にクライアント側が再接続するまでの時間を短くする方法を紹介します。 クライアントからサーバに接続するとソケットはESTABLISHEDになります。もしESTABLISHEDになったソケットで正しくパケットが送信されなかった場合、OSは再送を試みます。再送に失敗してソケットをクローズするまでの時間はOSの設定によります。 OSがTCP接続の異常を検知してからクローズするまでの時間を短くするには3つの方法があります。 パケットの再送回数を少なくする。 TCPレイヤでKeep Aliveパケットを送信する。この方法はTCP Keep Aliveに対応しているアプリのみ可能。 アプリケーションレイヤでKeep Aliveパケットを送信する。この方法はNullパケットを投げる等に対応して
Kazuho@Cybozu Labs: TCP通信ではデータの送信をまとめて行うべき、もうひとつの理由（＆ サーバのベンチマーク手法の話）
TCP通信をするプログラムを書く際に「データの送信はまとめて１回で」行うべき、というのは鉄則と言っていい、と思います。その理由としては、パケット数を最小限に抑えることでオーバーヘッドを少なくするためだと一般に説明されますが、自分はもうひとつポイントがあると考えています。次のグラフを見てください。 グラフは、一定量のデータを転送するのにかかる時間と使用するブロックサイズ（１回のwrite(2)で書き込むサイズ）の関係を表したものです注1。 ホスト間のTCP通信を行っている場合は、TCPのバッファが有効に機能するので、ブロックサイズ（＝パケット数の逆数）による速度の変化は、ほぼありません。一方、同一ホスト上で通信を行うと、ブロックサイズと反比例して所要時間が反比例の関係にあることがわかります。 原因は、同一ホスト上の通信では、送信プロセスがwrite(2)を呼ぶたびにコンテクストスイッチが発生
TCPの再送タイムアウトを制御したい
TCPの再送タイムアウトで最近まで知らなかったことがあったのでメモ。 たとえば、APサーバとDBサーバがあるとする。 AP-DB間のDBCPで使うTCPコネクションは、DBサーバがノードダウンしたのであればさっさと再送リトライをあきらめて切れてほしいと思うのが普通だろう。 このTCPの再送リトライ処理は、何もいじらないと15分以上続くので、 できればTCPコネクション単位で細かく調整させてほしいと思うのは人情だと思う。 Linux の場合、昔はこの調整をしようと思うと、sysctl を使って /proc/sys/net/ipv4/tcp_retries2 の値を書き換えるしかなかった。 これは、リトライ回数でしか指定できず、そのリトライ間隔が回数ごとに変わっていく（長くなる）のでわかりにくい上に、そのOS上の全TCPコネクションで有効になってしまうという問題があった。つまり、このオプション
Engine Yard Blog
We are proud to be working with our customers while they continue to enjoy our Engine Yard products. Here are some changes we are making
tcpflow: httpレスポンスボディをリアルタイムで見たいとき | Ore no homepage
tcpdumpの表示では見にくいし、pcapをいちいちwiresharkに食わせてfollow tcp streamするのは面倒。そんなときに使えるツール。 (1) tcpflow tcpflow(最新はgithubかな) http://www.circlemud.org/jelson/software/tcpflow/ https://github.com/simsong/tcpflow (2) インストール 自分のメモをペッと貼付けただけなので、バージョンやダウンロード先は適当に読みかえてください。 yum install libpcap-devel wget http://www.circlemud.org/pub/jelson/tcpflow/tcpflow-0.21.tar.gz tar xvfz tcpflow-0.21.tar.gz cd tcpflow-0.21 ./con
TCP高速化などを図ったLinuxカーネル3.6、リリース
TCP高速化などを図ったLinuxカーネル3.6、リリース：仮想環境でのI/O性能を改善するVFIOも Linuxカーネルの新バージョン、「Linux 3.6」が10月1日にリリースされた。Linus Torvalds氏はこのリリースについて、アーキテクチャやファイルシステムに大幅な変更はないとしながらも、「着実な進歩」だと表現している。 カーネル3.6では、まずネットワーク接続を高速化するため、TCP Small QueuesやTCP Fast Openといった機能が盛り込まれた。TCP Small Queuesは、1つのキューに含まれるパケットの数に上限を設けることでRTTなどを減らし、ひいてはバッファサイズに起因する遅延や輻輳といった問題（Bufferbloat）を解決することを狙ったもの。一方TCP Fast Openは、TCPコネクション確立時のプロセスを最適化することで、Web
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Velocity 2013 TCP Tuning for the Web
mPulse — Real User Performance Monitoring and Real-Time Analytics | Akamai