mongoDB の C ドライバを使ったプログラムでループしながらデータを登録するとき、接続切断を繰り返すと、パフォーマンスにどう影響するかを確認した。
設定
指定サイズのドキュメントを、Bulk 無しで Insert する。
テストパターン
A) mongo_open、mongo_get_collection を毎回コールする。(同、close 処理)
B) mongo_open、mongo_get_collectioin を最初に 1 回だけコールする。
C) mongo_open は最初に 1 回だけコール、mongo_get_collection は毎回コールする。
処理時間測定結果 (sec)
(ドキュメントサイズ 48 bytes の時)
ケース/登録件数 | 10,000 | 25,000 | 50,000 | 250,000 |
---|---|---|---|---|
A | 3 | 7 | 68 | 423 |
B | 0 | 2 | 4 | 18 |
C | 1 | 2 | 3 | 18 |
(ドキュメントサイズ 1,008 bytes の時)
ケース/登録件数 | 10,000 | 25,000 | 50,000 | 250,000 |
---|---|---|---|---|
A | 3 | 7 | 63 | 435 |
B | 0 | 3 | 4 | 23 |
C | 1 | 2 | 5 | 24 |
気付き
毎回の open/close (テストケースA) とそれ以外 (テストケースB,C) とでは
相当の処理時間差がみられるが、1 回のみの open (テストケースB) と
コレクション情報は毎回取得するケース (テストケースC) では有意差は
みられない。テストケースA の場合、netstat 情報で TIME_WAIT のコネクションが相当数
残ってしまっている。
(今回は、28,000 ほどのセッションがこのステータスで残っていました。)
CLOSE し終わっていない為、リソースは保持されたままになってしまうので、
毎回の処理は避けた方がいいのではないか。データがドロップしている理由については調査中。
(常に決まった件数近辺でドロップしているようなので、リソースの設定
などが関連しているものと思われる。)
-> 後の確認で、ソケットが作成できなかったことが原因でした。(ポートがいっぱいいっぱいで、接続ができていないタイミングがあった。)