Web サービスを利用する方、TCP リソース制限に注意（情報元のブックマーク数）
TCPソケットを明示的にCloseしないってので、トラブルを起こすことが結構多いですねぇ。インフラ担当としては、逐次Closeしてほしいです。
一台のコンピュータで利用できる TCP ソケットは、限りあるものです。
http://sqljp.com/yoshihirokawabata/archive/2009/09/15/26940.aspx
さらに、TCP ソケットが利用するメモリなどのリソースは、ファイルやプロセスのハンドルと同じ領域を利用します。
このため、多くのプロセスが動作するコンピュータ上で、一度に使える TCP ソケットは限定されており、使い切ってしまうと、TCP 接続ができなくなる上に、さまざまなエラーが発生する可能性があります。
また、TCP ソケットは、CLOSE 処理後も、一定時間 TIME_WAIT ステータスとして保持されます。
たとえば、Amazon API を使って、100冊の書籍情報を取り出すループ処理を行った場合、一時的に 100 個の TCP ソケットが消費されます。CLOSE してから、次の処理をしているから、瞬間的には 1 個 の消費とはなりません。
また、10 冊の書籍情報を表示する Web ページが 100 ページある Web サイトの場合、Google や Bing などの検索エンジンのクローラにより、すべてのページにアクセスが発生すると、10-100 = 1000 個の TCP ソケットを一時的に消費します。短時間に 1万ページ以上をアクセスするクローラーもあります。
実は、FireWallを挟むとFireWallが持っているステートフルインスペクション（TCPのセッション内部までチェックしている機能）のタイマー（タイマー＝セッション記憶数＝メモリ利用量）で通信ができなくなることがあります。
商用製品では、大体TCPで60分程度のタイマーとなっています。ですのでTCPをクローズしなかったり、Pool技術を使ってしまうと、夕方のセッション番号を朝一で使おうとして繋がらない事象とか発生します。
特にフレームワーク系で、データベースクエリー系でCLOSEしないものとかで苦労しました・・・orz
なお、SQL Server は、限りあるリソースを有効に利用するため、コネクションプール技術を提供しています。
http://sqljp.com/yoshihirokawabata/archive/2009/09/15/26940.aspx
コネクションプールにより、大量のデータベースアクセスを、クライアント・サーバーともに安定して処理します。
