クライアントアプリケーションのデザイン

大量のレコードを読み込むには Bulk API 2.0 が最適ですが、SOAP ベース API を使用することもできます。データ読み込み速度を改善するには、次のようなさまざまなアプリケーション設計方法があります。

• 永続接続を使用する。SSL/TLS ネゴシエーションからソケットステムを開く場合、時間がかかることがよくあります。SSL または TLS を使用しないと、API 要求は安全ではありません。HTTP 1.1 では、HTTP 1.0 のように要求ごとにソケットを開きなおす必要なく、要求間 (永続接続) でソケットを再利用することができます。使用するクライアントが永続接続をサポートしているかどうかは、使用している SOAP スタックによって異なります。デフォルトでは、.NET は永続接続を使用します。Apache http 共通ライブラリを使用するように設定を変更すると、クライアントは HTTP 1.1 仕様に準拠し、永続接続を使用します。

  HTTP 1.1 の詳細については、「HTTP 永続接続」および http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1 を参照してください。

• 要求数を最小化する。クライアントが要求ごとにできる限り多くのレコードを一括処理する時間を節約するような、各要求に関連する処理がいくつかあります。batchSize を上限 2,000 に設定します。これが最も効率的なバッチサイズでない場合、API がバッチサイズを変更します。バッチサイズの詳細については、「QueryOptions」を参照してください。
• 要求サイズを最小化する。クライアントアプリケーションは、1 つの要求でできるだけ多くのレコードを送信する必要がありますが、一方で送信する要求をできるだけ小さくしてネットワーク送信時間を短縮する必要もあります。要求サイズを最小化するには、要求および応答で圧縮を使用します。Gzip が最も一般的な圧縮方法です。Lightning プラットフォーム開発者向けコミュニティボードには、さまざまな SOAP スタックで圧縮を実施する方法について解説している複数の投稿があります。Gzip の詳細な分析および検証については、Simon Fell のブログ (http://www.pocketsoap.com/weblog/2005/12/1583.html) を参照してください。
• マルチスレッドのクライアントアプリケーションを設計しない。SOAP ベース API を使用する単一クライアントアプリケーションでは、マルチスレッドは許可されません。