Улучшения производительности WCF

Question

Я занимаюсь разработкой приложения WPF, которое общается с сервером через службы WCF через Интернет. После профилирования приложения я заметил, что много времени уходит на создание соответствующего клиентского прокси WCF и выполнение вызова на сервер.

Код на сервере оптимизирован и не требует времени для запуска. Я все еще наблюдаю 1,5-секундную задержку от момента вызова службы до ее возвращения клиенту.

Несколько пунктов, чтобы дать немного фона:

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

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

Может кто-нибудь предложить советы по производительности, которые помогут мне, пожалуйста?

Answer 1

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

• изолирует все контракты на обслуживание и данные в их отдельную сборку
• ссылка на эту сборку как на стороне сервера (для реализации вашего сервиса), так и на стороне клиента

Для этого вам не нужно создавать «универсальный» клиентский прокси с помощью Add Service Reference, но вместо этого вы можете разбить этот процесс на два отдельных шага:

• Первый шаг - создание ChannelFactory<T> с использованием вашего контракта на обслуживание, например,

  ChannelFactory<IMyService> factory = new ChannelFactory<IMyService>();
  

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

• второй шаг - создание фактического канала («прокси») из фабрики каналов:

  IMyService proxy = factory.CreateChannel();
  

  Эта операция намного менее ресурсоемка и может выполняться перед каждым вызовом службы и не должна вызывать значительных потерь времени.

Итак, выполнив несколько основных шагов, вы сможете значительно упростить и ускорить построение прокси-серверов клиента службы.