1. 1
NW遅延環境(Paas)での
チューニングTips
河原 翔
※Linux環境に基づいた内容です
PostgreSQLアンカンファレンス@東京 (7/13)

2. 2
NW遅延とは？
ネットワーク遅延とは、データを送信してから通信相手に届くまで
の時間と、その応答を通信相手が送信してから送信元に届くまでの合
計時間を指す。
つまりデータを入れたパケットが伝送経路を通過するのにかかる時
間（伝搬遅延）と、経路上のルーターなどの機器が処理する時間（処
理遅延）などを足し合わせたものだ。
LAN内であれば、ネットワーク遅延は1ミリ～3ミリ秒程度。しかし社
外にある国内のデータセンターとのやり取りでは十数ミリ秒、海外の
データセンターでは100ミリ秒を超えることもある。
ITproより引用
http://itpro.nikkeibp.co.jp/article/COLUMN/20121005/428005/
• 国外の会社が運営しているPaasのデータセンタは海外に
あることが多いため、NW遅延の影響を受ける可能性が高い
（Amazon等の大手は日本国内にもデータセンタがある）

3. 3
実際にどれくらいの影響があるのか？
• 無料で利用できる「Heroku Postgres」を利用
▫ 「Heroku Postgres」の詳細は割愛

4. 4
実際にどれくらいの影響があるのか？
• 約170msのNW遅延がある状態で、接続→SQL発行→切断の
時間を測定する
NW遅延
約170ms
さくらのVPS
大阪リージョン
$ psql "dbname=xxx-1.amazonaws.com /
user=yyy password=zzz port=5432 /
sslmode=require"
/
-c 'select * from test' > /dev/null
Heroku Postgres
=> table test;
val
----x
(1 row)

5. 5
実際にどれくらいの影響があるのか？
• クライアントがサーバ にTCPSYNパケットを送出してから
クライアントがサーバからRSTACKパケットを受信するまでの
時間は約1400msとなった
SSLセッション確立のための
時間が大半を占める

6. 6
実際にどれくらいの影響があるのか？
• クエリ発行前の各種コネクション確立のための時間が大半を
占めるため、初回確立後であれば、(ACK待ちが発生しなければ)
NW遅延1回分の影響のみで済む
$ psql "dbname=xxx-1.amazonaws.com user=yyy password=zzz port=5432 sslmode=require"
=> explain analyze table test;
QUERY PLAN
--------------------------------------------------------------------------Seq Scan on test (cost=0.00..1.00 rows=1 width=32)
(actual time=0.021..0.022 rows=1 loops=1)
Total runtime: 0.103 ms
(2 rows)
=> ¥timing
Timing is on.
=> table test;
val
-------x
(1 row)
Time: 183.563 ms
=>
explainではデータ転送時間は含まれない模様
※auto_explainの対象にならない
¥timingではデータ転送時間も含まれる模様

7. 7
【対応策】
• コネクションプーリングを利用する
▫ 初回接続時の各種コネクション確立のコストを
抑えるため
 プロセス生成と終了のコストを抑えるためではない
 各種コネクション確立後であれば、ACK待ちが発生しなければ
NW遅延1回分の影響のみで済む
▫ pgpoolはVer2.3.2からSSLをサポート
▫ PgBounserはSSLは不可？

8. 8
【対応策】
• クエリの発行回数を抑える
▫ ストアドプロシージャを利用する
 とあるOSSのブログシステムでは、画面遷移の度にクエリが
20回以上発行されることも…
▫ 一度のクエリで送受信するデータ量を増やす
 一度のINSERT文で複数レコード挿入可能なことを知らない
エンジニアも結構いるかと…
 ただし、ACK待ちは発生させないように考慮すること

9. 9
ACK待ちとは？
TCPでは、ACKの応答確認により信頼確保されているが、パケットを送
信する度にACKを送信していてはさすがに通信速度が遅くなってしまい
ます。そこでTCPヘッダにあるウィンドウサイズを利用することにより
この問題を解決しています。ウィンドウサイズとは、ACKを待たずに一
度に送信できるデータ量のことです。
例えば、3900バイトのデータを3回に分けて送信する場合、1300バイ
トのデータを送るたびにACKを待っていると通信速度は遅いですが、
ウィンドウサイズが「3900」であることを相手側のホストに伝えた場合、
送信側はACKを待つことなく3900バイトのデータを送信することができ
ます。これにより通信速度が速まる。
※ ちなみに、Windows XPの受信ウィンドウサイズはデフォルトで
「65535」バイトとなります。ウィンドウサイズはOSにより異なります。
しかし、これではウィンドウサイズ分のデータを送信した後、ACKを
受信するまでの間、待ち時間が発生する。
「ネットワークエンジニアとして」より引用
http://www.infraexpert.com/study/tcpip11.html

10. 10
ACK待ちを考慮する必要は？
• 1クエリでのデータ送信量が数十KB以上あるような
ケースでなければACK待ちが発生する可能性は低い
▫ 新しめのLinux Kernelは初期ウィンドウサイズが
10と大きめに設定されているため、ACK待ちは発生し
難くなっている
▫ デフォルトでsslcompressionはONであるため、
SSL接続でのデータ転送は自動的に圧縮される
 ACK待ちが発生するかを事前に計算して
正確に推測することは困難
▫ TCPのチューニングが可能であることは意識すべき
 tcp_slow_start_after_idleはoffにするとか…

11. 11
【要点】
• コネクションプーリングを利用する
▫ 初回接続時の各種コネクション確立のコストを抑える
 プロセス生成と終了のコストを抑えるためではない
• クエリの発行回数を抑える
▫ ストアドプロシージャを利用する
▫ 一度のクエリで送受信するデータ量を増やす
• ACK待ちの影響を最小限にする
▫ 1クエリでのデータ送信量を、ACKを受信せずに
一度に送信できるデータ量以下に収めるようにする
▫ TCP初期ウィンドウサイズの大きいKernelを採用する