Использование WCF в приложении ASP.Net и лучшие практики

Question

Я совершенно новичок в WCF. Я был почти уверен, что он будет работать как обычные веб-сервисы - и я также уверен, что я тоже делал это неправильно, но теперь я хочу убедиться, что я делаю это правильно.

Наше приложение ASP.Net подключается к службе WCF через Интернет. Я реализовал базовую безопасность и использую SSL. Это работает, но медленнее, чем когда мы работали с обычными веб-сервисами. Возвращаемые данные в основном такие же, как и в обычном веб-сервисе.

Когда я использовал обычный веб-сервис, в любое время, когда мне нужно было получить данные, я создавал новый сервисный объект и вызывал функцию для нужных мне данных. Казалось бы, это работает нормально, но, как я полагаю, это не лучший способ сделать это, особенно если одновременно подключались тысячи пользователей. Поэтому, когда я перешел на WCF, я решил оставить одного клиента открытым и просто использовать его для всех, кто подключается к сайту. Я поместил его в кеш, и когда в кеш выводился объект, у меня была функция обратного вызова для его удаления.

Теперь я даже не думал об этом до тех пор, пока не изменил все, что могло бы создать проблему для нескольких людей, соединяющихся. Если человек А запрашивает данные, человек Б должен дождаться его завершения, прежде чем его данные будут получены через службу.

Так что я изменил его на сессионное. Я либо реализовал это неправильно, либо он просто имел неприятные последствия, так как он не работал вообще. У клиента будет тайм-аут, причина ошибки или просто не работает. Я изменил его обратно на кеширование, и теперь оно работает нормально (кроме медленного).

Что такое «лучшая практика» для этого сценария? Могу ли я создать клиента на лету, когда это необходимо, создать один сеанс на основе (и выяснить, что я сделал не так) или оставить его как есть и использовать метод кэширования с одним клиентом?

Answer 1

Такую проблему обычно решают, поддерживая пул. Вместо того чтобы иметь только один объект службы в одном экстремуме и один на пользователя в другом экстремуме, пул будет содержать коллекцию объектов службы, которые необходимы для поддержки постоянного спроса на их услуги. Следовательно, пул должен расти только до точки максимального спроса.

Вы должны убедиться, что объекты выпали из пула до любого другого тайм-аута изнутри объекта службы, а также убедиться, что они выпали, если у них есть какое-либо исключение.

Таким образом, у вас нет нескольких клиентских запросов, ожидающих доступа к одному объекту, и при этом у вас нет незанятых объектов, слоняющихся в службе и, вероятно, умирающих от старости, прежде чем они могут быть снова использованы в любом случае.

Answer 2

В общем случае наилучшей практикой для сервисов WCF будет, по возможности, иметь модель для отдельного экземпляра для каждого вызова. Это дает вам лучшую пропускную способность, лучшее и простое поведение в экземпляре службы. Поэтому, когда это возможно, и если у вас нет действительно веских причин, используйте эту модель.

Похоже, что в вашем случае создание экземпляра службы является довольно дорогой операцией. Возможно, вам нужно как-то это исправить - сделать экземпляр службы очень легким и легким, чтобы его можно было создать и утилизировать в мгновение ока (или меньше), а затем иметь некоторые фоновые рабочие процессы (или, возможно, пул) из тех, которые предложены Энтони), которые вы можете затем вызвать из ваших реальных экземпляров службы.

Марк

Answer 3

Я обычно создаю клиента на лету, как вы упомянули, но убедитесь, что вы утилизируете его после завершения запроса. Я сделал это без большой проблемы, но, честно говоря, у меня не более 1000 пользователей, одновременно обращающихся к одному и тому же сервису.

Точную информацию о реализации вы можете найти в этом блоге, если вам интересно.

Просто чтобы уточнить то, что вы упомянули в вопросе - когда вы говорите "обычный веб-сервис", вы говорите об ASMX или?