Yoichi Kawasaki's Web » debian http://yk55.com/blog the place to organize and record my ideas ... Sun, 05 Feb 2012 15:16:55 +0000 en hourly 1 http://wordpress.org/?v=3.0.1 cURL MultiインターフェースでHTTP Pipeliningリクエストの送信 http://yk55.com/blog/2010/04/20/curl_multi_http_pipelining_reques/ http://yk55.com/blog/2010/04/20/curl_multi_http_pipelining_reques/#comments Tue, 20 Apr 2010 14:54:54 +0000 yoichi http://yk55.com/blog/?p=303 cURLのC APIマニュアルを読んでいたらCURLMOPT_PIPELININGというおもしろそうなオプションを見つけた。これはlibcurl 7.16.0 より加わった並列実行用Multiインターフェースのオプションで、設定することでHTTP Pipeliningなリクエストが送信できるようになる。HTTP Pipeliningとは個々のレスポンスを待つことなく複数のリクエストを投げることを意味するHTTP/1.1よりサポートされた通信パフォーマンス向上のためのテクニックである。

通常N個のリクエストを処理する際はN個ソケットがオープンされOPEN → REQUEST → RESPONSE → CLOSEなサイクルがN回行われる。Multiインターフェースによる並列処理の場合はOPEN → REQUEST → RESPONSE → CLOSEが並列に行われる。 またこれがkeep-aliveな接続であればOPEN → (REQUEST → RESPONSE) x N → CLOSEのようにクローズされるまで１ソケットが再利用される。 そしてHTTP Pipeliningはkeep-aliveな接続で使うテクニックであり、これが有効な場合は1ソケットオープン後にOPEN → (REQUEST x N) → (RESPONSE x N) → CLOSEのようにリクエストN個をレスポンスを待つことなく1ソケットに書き込むことができる。 まとめて送信される分パケット効率がアップし全体的なネットワークを流れるパケットの数を減らすことができ、 さらにまとめてリクエスト送信するので高レイテンシーなネットワークにおいては速度面で効果的といえる。 see also 「Mozilla HTTP/1.1 パイプライン化 FAQ」。

(1) NOT keep-alive, single         (OPEN → REQUEST → RESPONSE → CLOSE) x N
(2) NOT keep-alive, multi          (OPEN → REQUEST → RESPONSE → CLOSE) をN並列で行う
(3) keep-alive                     OPEN → (REQUEST → RESPONSE) x N → CLOSE
(4) keep-alive, Pipelining         OPEN → (REQUEST x N) → (RESPONSE x N) → CLOSE

というわけでいつものようにテストプログラムを作ってMultiインターフェースによる並列処理をHTTP Pipeliningありとなしで実行してみる。
(環境 libcurl-7.19.5、httpd-2.2.2 on Debian-5.0.1 )

テストツールとそのコンパイル

cURL CAPIのMultiインターフェースを使って複数URLからfetchしてくるツールを作成した。

http://github.com/yokawasa/any/blob/master/libcurl/multi_fetch.cpp

標準的なcurl Multiインターフェースを使ったコードであるがポイントは次の部分。各リクエスト用のCURLハンドルでソケットの送信待ち時間を最小限にするCURLOPT_TCP_NODELAYオプション（詳しくは「Linuxにおけるソケット機能の向上」を参照ください）と挙動把握のためにlibcurlのINFO情報を出力するCURLOPT_VERBOSEオプションを有効にしている。またHTTP Pipeliningモード指定のときにMulti用ハンドルでCURLMOPT_PIPELININGオプションを有効にしている。　以下該当箇所のコード断片。

...
for(vector<string>::iterator it=urls.begin();
            it!=urls.end(); ++it) {
    curl_easy_setopt(c_handles[i], CURLOPT_URL, (*it).c_str());
    curl_easy_setopt(c_handles[i], CURLOPT_TCP_NODELAY, 1L);
    curl_easy_setopt(c_handles[i], CURLOPT_VERBOSE, 1L);
    curl_multi_add_handle(m_handle, c_handles[i]);
    i++;
}
if (pipelining)
    curl_multi_setopt(m_handle, CURLMOPT_PIPELINING, 1L);
...

上記URLのソースコードを取得して次のようにコンパイルを行う。

g++ multi_fetch.cpp -o multi_fetch -I/usr/include -L/usr/lib -lcurl

使い方は次のように複数URLの書かれたファイルを指定する。-pオプションを加えてやることでHTTP Pipeliningモードでリクエスト送信を行う。 これはオプショナル。

Usage: ./multi_fetch <options>
Options: -f file  URL list file
         -p       HTTP pipelining mode (optional)
 
例) urls.txtに書かれた複数URLからHTTP Pipeliningモードでfetch
$ ./multi_fetch -f urls.txt -p

NON HTTP Pipelining リクエスト送信

テスト用にホストfooとWebサーバ（apache）のあるホストbarを用意する。まずはHTTP Pipeliningオプションをはずした通常のmultiインターフェースによる並列実行を行う。リクエスト用CURLハンドルでCURLOPT_VERBOSEオプションが有効になっているので実行結果にlibcurlのINFO 情報も一緒に出力される。出力内容を全てここに貼り付けるには量が多すぎるので内容を簡略化してHTTP接続部分と各リクエストとそのレスポンスの最初の一行だけに絞る。

$ cat urls.txt
http://bar.yk55.com/test1.html
http://bar.yk55.com/test2.html
http://bar.yk55.com/test3.html
http://bar.yk55.com/test4.html

$ ./multi_fetch -f urls.txt  2>&1 |tee /tmp/nonpipelined.out
[出力結果]
$ cat /tmp/nonpipelined.out

* About to connect() to bar.yk55.com port 80 (#0)          
* About to connect() to bar.yk55.com port 80 (#1)
* About to connect() to bar.yk55.com port 80 (#2)
* About to connect() to bar.yk55.com port 80 (#3)
* Connected to bar.yk55.com (192.168.1.5) port 80 (#0)
* Connected to bar.yk55.com (192.168.1.5) port 80 (#1)
* Connected to bar.yk55.com (192.168.1.5) port 80 (#2)
* Connected to bar.yk55.com (192.168.1.5) port 80 (#3)
> GET /test1.html HTTP/1.1                                      
> GET /test2.html HTTP/1.1                                      
> GET /test3.html HTTP/1.1                                      
> GET /test4.html HTTP/1.1                                      
< HTTP/1.1 200 OK                                                  
* Connection #1 to host bar.yk55.com left intact          
< HTTP/1.1 200 OK                                                  
* Connection #2 to host bar.yk55.com left intact          
< HTTP/1.1 200 OK                                                  
* Connection #3 to host bar.yk55.com left intact          
< HTTP/1.1 200 OK                                                  
* Connection #0 to host bar.yk55.com left intact

これを見ると並列にConnection #[0-3]の4つのソケットがオープンしてそれぞれにリクエスト、レスポンスが書き出され終了していることが分かる。 「(2)NOT keep-alive, multi」のパターンになっているといえる。想定どおり。

HTTP Pipeliningリクエスト送信

次に前テストと同様にホストfooからホストbar(Webサーバ)の4ファイル対してにHTTP Pipeliningなリクエストを送信してみる。

$ cat urls.txt
http://bar.yk55.com/test1.html
http://bar.yk55.com/test2.html
http://bar.yk55.com/test3.html
http://bar.yk55.com/test4.html
 
$ ./multi_fetch -f urls.txt -p　 2>&1 |tee /tmp/pipelined.out
[出力結果]
$ cat /tmp/pipelined.out

* About to connect() to bar.yk55.com port 80 (#0)
* Re-using existing connection! (#0) with host bar.yk55.com
* Re-using existing connection! (#0) with host bar.yk55.com
* Re-using existing connection! (#0) with host bar.yk55.com
* Connected to bar.yk55.com (192.168.1.5) port 80 (#0)
> GET /test1.html HTTP/1.1                                        
< HTTP/1.1 200 OK                                                    
> GET /test2.html HTTP/1.1                                        
> GET /test3.html HTTP/1.1                                        
> GET /test4.html HTTP/1.1                                        
< HTTP/1.1 200 OK                                                    
< HTTP/1.1 200 OK                                                    
< HTTP/1.1 200 OK                                                    
* Connection #0 to host bar.yk55.com left intact

出力結果から、1つのソケットオープン(Connection #0)後に他のリクエスト達はConnectoin#0を 再利用しているのが分かる。 またtest1.htmlをGETするためのリクエスト送信後に「HTTP/1.1 200 OK….」とレスポンスを受け、次にtest2.html～test4.html GETの3リクエストがレスポンスを待つことなく連続で送られ、その後それらのレスポンスを受けている。 「(4) keep-alive, Pipelining」のパターンになると予想していたのだが１つ目のリクエスト（REQUEST-a）だけがPipeliningではない。 試しにリクエスト数を増やしてみても同じ、１つ目のリクエストがPipeliningではなく、2番目以降のリクエストはPipeliningになっている。 今一理由がわからない。 ひょっとして実際の処理とは別にログ出力に問題があるのではないかと思いtcpdumpで実際のTCPパケットのやりとり確認してみる。

$ sudo tcpdump -lX -s 1024 -i eth0 port 80 |tee /tmp/tcpdump.txt
$ cat /tmp/tcpdump.txt

*** SYN: Socketオープン
01:27:14.155974 IP foo.43242 > bar.http: S 3856091341:3856091341(0) win 5840 <mss 1460,sackOK,timestamp 31004352 0,nop,wscale 6>
01:27:14.158135 IP bar.http > foo.43242: S 2366776094:2366776094(0) ack 3856091342 win 5792 <mss 1460,sackOK,timestamp 224898337 31004352,nop,wscale 2>
01:27:14.158197 IP foo.43242 > bar.http: . ack 1 win 92 <nop,nop,timestamp 31004352 224898337>

*** PUSH: 1stリクエスト
01:27:14.156012 IP foo.43242 > bar.http: P 1:63(62) ack 1 win 92 <nop,nop,timestamp 31004352 224898337>
01:27:14.156080 IP bar.http > foo.43242: . ack 63 win 1448 <nop,nop,timestamp 224898337 31004352>

*** PUSH: 1stレスポンス
01:27:14.158768 IP bar.http > foo.43242: P 1:198(197) ack 63 win 1448 <nop,nop,timestamp 224898340 31004352>
01:27:14.158930 IP foo.43242 > bar.http: . ack 198 win 108 <nop,nop,timestamp 31004353 224898340>

*** PUSH: 2nd, 3rd, 4thリクエスト
01:27:14.159183 IP foo.43242 > bar.http: P 63:125(62) ack 198 win 108 <nop,nop,timestamp 31004353 224898340>
01:27:14.159277 IP foo.43242 > bar.http: P 125:187(62) ack 198 win 108 <nop,nop,timestamp 31004353 224898340>
01:27:14.159361 IP foo.43242 > bar.http: P 187:249(62) ack 198 win 108 <nop,nop,timestamp 31004353 224898340>

*** PUSH:  2nd, 3rd, 4thまとめてレスポンス
01:27:14.163514 IP bar.http > foo.43242: P 198:789(591) ack 249 win 1448 <nop,nop,timestamp 224898344 31004353>

*** FIN:  Socket クローズ
01:27:14.164128 IP foo.43242 > bar.http: F 249:249(0) ack 789 win 127 <nop,nop,timestamp 31004354 224898344>
01:27:14.164634 IP bar.http > foo.43242: F 789:789(0) ack 250 win 1448 <nop,nop,timestamp 224898345 31004354>
01:27:14.164780 IP foo.43242 > bar.http: . ack 790 win 127 <nop,nop,timestamp 31004354 224898345>

tcpdumpの結果も変わらず同じ。 ログを見る限りオープン処理（SYNフラグの出力部分、いわゆる3way handshake）が行われた後、１つ目のリクエスト直後にレスポンスを受け、その後2番目以降のリクエストはレスポンスを待つことなくソケット書き込み、つまりPipeliningリクエスト送受信が行われている。　どうして１つ目だけがダメで、２つ目以降からうまくいくのだろう？？ (T . T)

細かくlibcurlのコードを追えばよいのだろうがこれ以上調査する気持ちにならないので取り敢えずここで終えておく。 続きはいつか。

おわり。

]]> http://yk55.com/blog/2010/04/20/curl_multi_http_pipelining_reques/feed/ 5 簡単Boehm GCによるC/C++メモリリーク検知 http://yk55.com/blog/2010/03/25/boehm_gc_detect_memory_leak/ http://yk55.com/blog/2010/03/25/boehm_gc_detect_memory_leak/#comments Thu, 25 Mar 2010 14:37:54 +0000 yoichi http://yk55.com/blog/?p=269 Boehm GCはガベージコレクションの標準実装がないC/C++でガベージコレクションのようなことを実現可能にしてくれるライブラリ。 一度確保されたリソースは明示的に解放処理が行われない限りメモリリークが発生してしまうけれどもBoehm GCで用意されている関数群（通常はGC_MALLOC）を使ってリソースを確保すれば不要になった段階で自動的に解放してくれる。 ソースコード全体で統一してこのライブラリを利用していればオブジェクトの寿命管理の手間は減るだろうし自分がコードの責任者であるならば難しいところを枯れたライブラリにお任せできるので安心感はあるのだろう。ちなみにこのライブラリ、以前からその存在は知ってはいたけれどスマートポインタ派の自分としてはオブジェクトの寿命管理のためにこれを使うモチベーションはいまいち感じられない。

そんなBoehm GCは「Using the Garbage Collector as Leak Detector」で紹介されているようにメモリリーク検知用ユーティリティとしても使える。ドキュメントやソースコードを覗いてみて少し工夫すれば手軽に既存のコードに殆ど手を加えること無くメモリリークの検知ができそうだったので試しにサンプルコードを書いてみた。以下、Boehm GCのインストールからC/C++コードでのメモリリーク検知について。

Boehm GCインストール

まずは自分の環境(debina5.0.1″lenny”)にBoehm GCをインストールしてみる。 Boehm GCライブラリをつかって開発するにはlibgc-devとlibgc1c2が必要。もし自分の環境に合うパッケージが存在しない場合は直接ここから tar.gzボールをダウンロードして例のconfigure、make、make install。

$ sudo apt-get install libgc-dev
$ sudo apt-get install libgc1c2
$ dpkg --list |grep libgc
ii  libgc-dev                       1:6.8-1.1                conservative garbage collector for C (develo
ii  libgc1c2                        1:6.8-1.1                conservative garbage collector for C and C++

Cコードメモリリーク検知 – *alloc/freeをGC_関数に置換

Boehm GCにはGC_MALLOC等のリソース確保系関数でリソース確保されたにもかかわらずGC_FREE等の解放系関数でリソース解放されずにリークしてしまっているオブジェクトを検知してそれらをレポートする機能がある。 このメモリリーク検知レポートはGC_gcollect関数で実行される。ただしこのときメモリリーク検知レポート機能をオンにするためにはそもそもBoehm GC を-DFIND_LEAKオプションでコンパイルするか、または実行時にダイナミックにGC_find_leak=1をセットしてやる必要がある。

  • 対象オブジェクト: GC_MALLOC等でリソース確保されたにもかかわらずGC_FREE等で解放されないオブジェクト
  • 検知レポート実行関数： GC_gcollect
  • 前提条件： -DFIND_LEAKオプションでコンパイルされたBoehmGC or 実行時にGC_find_leak=1をセット

「Using the Garbage Collector as Leak Detector」ではこのメモリリーク検知レポート機能を利用して実際のCコードのメモリリークを検知するために直接ヒープからメモリ確保、解放を行うための基本関数をBoehmGCの関数で置き換えるためのヘッダを用意している。

gc_detect_leaks.h

#define GC_DEBUG
#include "gc.h"
#define malloc(n) GC_MALLOC(n)
#define calloc(m,n) GC_MALLOC((m)*(n))
#define free(p) GC_FREE(p)
#define realloc(p,n) GC_REALLOC((p),(n))
#define CHECK_LEAKS() GC_gcollect()

試しにメモリリークを引き起こすコードに上記ヘッダをインクルードしたサンプルコード(t1.c)を用意してコンパイル+ 実行してみる。
サンプルコード: t1.c

#include <stdio.h>
#include "gc_detect_leaks.h"
int main() {
    GC_find_leak = 1;
    char *a;
    while(1){
        a = (char*)malloc(100);　　// t1.c: line7
        //free(a);
        CHECK_LEAKS();
    }
}
[コンパイルと実行結果]
$ gcc -g -Wall t1.c -o t1 -I/usr/include/gc -L/usr/lib -lgc
$ ./t1
Leaked composite object at 0x805af90 (t1.c:7, sz=100, NORMAL)
Leaked composite object at 0x805af10 (t1.c:7, sz=100, NORMAL)
Leaked composite object at 0x805af90 (t1.c:7, sz=100, NORMAL)
...

無事メモリリークを検知。メモリリークの原因となっている箇所（t1.cの７行目）も特定されているので合格。ちなみに上記ヘッダでGC_DEBUGをdefineしているは理由はgc.hで定義されているGC_MALLOCをデバック用出力にモードにするため。以下gc.hの該当部分だけを略して抜粋。

gc6.8 – /usr/local/gc/gc.h

#ifdef GC_ADD_CALLER
#  define GC_EXTRAS GC_RETURN_ADDR, __FILE__, __LINE__
...略...
#else
#  define GC_EXTRAS __FILE__, __LINE__
...略...
#endif

# ifdef GC_DEBUG
#   define GC_MALLOC(sz) GC_debug_malloc(sz, GC_EXTRAS)
... 略...
# else
#   define GC_MALLOC(sz) GC_malloc(sz)
...略...
# endif

C++ コードメモリリーク検知 – gc/gc_cleanupクラスで継承

次にC++コードのメモリリーク検知を行う。C++のデータ構造の基本はクラス（細かいことを省けば構造体もクラス）でありクラスはnewオペレーターでメモリを動的に確保する。 当然のことながらデフォルトのnewオペレータでリソース確保した場合はGC回収不能であるためBoehm GCが用意しているC++用ライブラリを利用する。gc_cpp.hをみるとこれは単なるCライブラリのラップクラス。以下のようにgcやgc_cleanupクラスをベースクラスとすることでGC回収可能なオブジェクトとして扱うことができる。

サンプルコード: t2.cpp

#include <stdio.h>
#define GC_DEBUG
#include "gc_cpp.h"
#define CHECK_LEAKS() GC_gcollect()
class Foo: public gc{};
int main() {
    GC_find_leak = 1;
    Foo *f;
    while(1){
        f =new Foo;　　　// t2.cpp: line10
//        delete f;
        CHECK_LEAKS();
    }
}
[コンパイルと実行結果]
$ g++ -g -Wall t2.cpp -o t2 -I/usr/include/gc -L/usr/lib -lgc
$ ./t2
Leaked composite object at 0x805afe8 (/usr/include/gc/gc_cpp.h:274, sz=1, NORMAL)
Leaked composite object at 0x805afd0 (/usr/include/gc/gc_cpp.h:274, sz=1, NORMAL)
Leaked composite object at 0x805afe8 (/usr/include/gc/gc_cpp.h:274, sz=1, NORMAL)
....

これも無事メモリリーク検知はされている。ただしリーク箇所が/usr/include/gc/gc_cpp.hのL274行目を指している。これではリークの原因箇所がわからない。できればt2.cppのL10行目(f=new Foo)を指してもらいたい。さらにこの方法では単に既存のコードのメモリーリーク検知のみを行いたい場合でも、クラスをgc やgc_cleanupクラスで継承させるといったコードに手を加えていく作業が必要があるのでとても面倒でありコード量が多ければ多いほど手間がかかる。

C++コードメモリリーク検知 – new/deleteオペレータのオーバーロード

そこで既存のコードにあまり手を加えなくてもメモリリーク検知ができ、且つリークの原因箇所を特定できる方法を考えてみた。まずは既存のコードの手を加えないでメモリリーク検知する方法。クラスはリソースの確保、解放をそれぞれnew、 deleteオペレータで行うのでこれらをグローバルにオーバーロードしてやり内部のリソース確保、解放のための実装をGC関数で置き換えてやる。そしてそのヘッダを既存のコードにインクルードしてやれば既存のコードに手を加えないでメモリーリークの検知ができるのではないかと。 ヘッダは以下のような感じ。

#define GC_DEBUG
#include "gc.h"
void* operator new(size_t size) {
    return GC_MALLOC(size);
}
void* operator new[](size_t size) {
    return GC_MALLOC(size);
}
void operator delete(void* p) {
    if (p) GC_FREE(p);
}
void  operator delete[](void* p) {
    if (p) GC_FREE(p);
}

ただしこれだけではメモリリークの検知はできてもリークの原因箇所の特定が難しい。このままだと上記ヘッダのGC_MALLOC()コール箇所がリーク箇所としてレポートされてしまう。 理想はnewオペレータをコールしている箇所がレポートされて欲しい。ということで次のように GC_debug_malloc()にnewオペレータコール箇所のファイル名と行を渡すように変更してみる。

gc_detect_leaks.h

#define GC_DEBUG
#include "gc.h"
void* operator new(size_t size, const char * s, int i) {
    return GC_debug_malloc(size,s,i);
}
void* operator new[](size_t size,  const char * s, int i) {
    return GC_debug_malloc(size,s,i);
}
void operator delete(void* p) {
    if (p) GC_debug_free(p);
}
void  operator delete[](void* p) {
    if (p) GC_debug_free(p);
}
#   define new new(__FILE__, __LINE__)
#   define CHECK_LEAKS() GC_gcollect()
int GC_find_leak = 1;

ためしにメモリリークを引き起こすC++コードに上記ヘッダをインクルードしたものを用意してコンパイル+ 実行してみる。今度はヘッダにint GC_find_leak = 1を含めているのでサンプルコードにGC_find_leak = 1をセットする必要はない。

サンプルコード: t3.cpp

#include <stdio.h>
#include "gc_detect_leaks.h"
class Foo{};
int main() {
    Foo *f;
    while(1){
        f =new Foo;     // t3.cpp: line7
//        delete f;
        CHECK_LEAKS();
    }
}
[コンパイルと実行結果]
$ g++ -g -Wall t3.cpp -o t3 -I/usr/include/gc -L/usr/lib -lgc
$ ./t3
Leaked composite object at 0x805afe8 (t3.cpp:7, sz=1, NORMAL)
Leaked composite object at 0x805afd0 (t3.cpp:7, sz=1, NORMAL)
Leaked composite object at 0x805afe8 (t3.cpp:7, sz=1, NORMAL)
...

見事メモリリークを検知しnewオペレータをコールしている行がレポートされた。というわけでこのヘッダをインクルードするだけで他の既存のコードに手を加えることなくメモリリークを検知することができた。

最後に、今回使ったサンプルコードとここで紹介したヘッダを少し体裁を整えてgithubにあげておきました。ちなみにgithubにあげたgc_detect_leaks.hを使う際は-DGC_DETECT_MEM_LEAKでコンパイルすることをお忘れなく。

http://github.com/yokawasa/any/tree/master/boehmgc/

おわり

]]> http://yk55.com/blog/2010/03/25/boehm_gc_detect_memory_leak/feed/ 0