私を正しい方向に向けるには、助けが必要です。
WebHTTPエンドポイントを介してサービス機能（SQL Serverデータベースの読み取りと更新で構成される）を呼び出しごとのサービスとしてユーザーに公開したいと考えています。他のプラットフォームでこれを相互運用させるのに問題があるため、回避できる場合はSOAPを使用したくありません。これは1000人以上のユーザーにスケーラブルである必要があり、このシナリオでは、多くの同時リクエストを送信する可能性はほとんどありません。いつでも最大25の同時リクエストがあるはずです。
（これが、セッションごとのサービスが除外された理由です。これは、25のアクションのみが実行されている間、1000以上のセッションを開いたままにすることを意味するためです。）
ただし、テストサービスの経験から、HTTPを介した純粋なPer-Call WCFサービスの使用はパフォーマンスが低く、最大の時間経過はSQLサーバー接続の初期化であることがわかります。
これは、Webサーバーが通常遭遇するシナリオと似たようなシナリオです。したがって、Webサーバーと同様のアプローチを使用するのが賢明であるように見えました。パフォーマンス上の理由から、HTTPエンジンのプールをアクティブに保ち、着信要求にはプール内のエンジンの1つが割り当てられています。
したがって、25〜30個の「ビジネスロジックオブジェクト」（つまり、実際のサービスロジックが単なるサービスインターフェイスから切り離されたクラス）のプールを開いたままにして、サービスホストの起動時にインスタンス化する必要があります。
WCFには、これをすぐにサポートするシナリオが組み込まれていないようです。どうすればいいですか？
セルフホスティングの場合、ServiceHostからカスタムクラスを派生させ、Businessオブジェクトを使用してディクショナリを追加できます。これにより、手動同期で処理する必要があると思われるスレッドの問題が発生します。
IISでホストすることにした場合、IISがServiceHostクラスのインスタンスの作成を自動的に処理し、その間に独自のカスタムホストをスローする機会があまりないため、どのように実行しますか？ ？
それとも、これはまったく悪いアプローチですか。他のアイデアはありがたいです。