5

REST クライアント要求を処理するバックエンド MS SQL Server 2008 (同じサーバー ボックス) に接続された Delphi XE2 DataSnap サーバー (Windows サービス) があります。
最近まで、すべてがうまく機能していましたが、何らかの理由で DataSnap サービスが SQL Server への接続を失ったという問題がありました。

サービスは接続を再確立できず、続行するには DataSnap サービスを再起動する必要がありました。
現在、サービスはすべてのクライアント要求に対して共有される 1 つの SQL 接続 (TADOConnection) のみを使用しているため、これは私に考えさせました。これを行ったのは、クライアントの要求ごとに新しい SQL 接続をインスタンス化するオーバーヘッドが必要なかったからです。

リクエストごとに個別のSQL接続を使用する方が実際に良いかどうか、またオーバーヘッドが目立つかどうかを検討しています-これについて誰かコメント/アドバイスできますか?

4

1 に答える 1

3

これは、さまざまなアプローチを試すために変更でき、データベース接続をコードの残りの部分から分離できる、適切に構築されたデータ アクセス レイヤーを持つことが非常に役立つ場所です。

クライアントから DataSnap サーバーに MIDAS (DataSnap) を使用している場合は、接続のオーバーヘッドが大きいことがわかっているため、プーリング アプローチ (mjn が提案) を強くお勧めします。

実行時にプレーンな TADOConnection を使用するいくつかの Web サービス (トラフィックがかなり少ない) を構築しましたが、データベース接続を確立するためのオーバーヘッドは、デバイスからサーバーへの全体的なネットワーク遅延と比較して、無視できるほど小さいことがわかりました。戻る。
高トラフィック環境で TADOConnection のオーバーヘッドが依然として大きすぎる場合は、上記のような独自の接続プールをそのようなシステムに簡単に追加できます。

于 2012-11-30T16:44:05.110 に答える