johannesnestler
Привет, йог@FLG,
Вы не упомянули, как вы вызываете свою службу WCF из своего приложения (?). Если вы действительно хотите узнать о производительности, вы должны протестировать ее на производственной среде, близкой к nnvironment. Вы упоминаете свой антивирус - это не очень хороший признак вашего понимания тестов производительности (скорее всего, вы используете какой-то инструмент проверки сети, а не только антивирус). Забудьте об этом, используйте только скомпилированный и запущенный (JITTED) код для сравнения производительности на производственной платформе или системе минимальных требований - чем делать свои выводы.
Не говоря уже о том, что логично, что прямой вызов всегда будет быстрее, чем прохождение сервисного вызова (вы понимаете, как это работает?), но это по природе темы - вы создаете сервисы, чтобы сделать технические независимые, многоразовые детали, а не для производительности!
Вы не упомянули свой конкретный сценарий, поэтому довольно трудно дать хороший совет.
Но для WCF мне приходят в голову некоторые вещи, которые вы, возможно, захотите рассмотреть.
* Протокол сообщений/данных/сериализация-SOAP/JASON (насколько глубоки ваши объектные графики?) Вы разрабатывали свои методы обслуживания с учетом этого (я стараюсь использовать как можно меньшую передачу информации, например, если мне нужен заказ для клиента, я отправляю весь объект клиента, если вам нужен только идентификатор клиента для выбора заказов из вашего хранилища данных).
* Попробуйте смоделировать различные задержки сети.
* Если потребность в данных очень высока и вы ничего не можете с этим поделать - возможно, рассмотрите различные шаблоны (подкачка данных, кэширование или фоновая синхронизация)-например, в текущем проекте я использую виртуализацию данных на стороне клиента, которая изначально загружает только 3 страницы данных.)
* Зависит от того, как вы вызываете свой сервис wcf (Throgh Proxy?), но если вы создаете channelfactory и channels on demand: лучше всего хранить channelfactories для каждого контракта, который вы вызываете, в кэше (подойдет простой словарь) - поэтому создавайте их только один раз в вашем приложении, а затем создавайте / отбрасывайте новые каналы по мере необходимости из ваших кэшированных channelfactories (создание фабрики-дорогостоящая задача, создание каналов из кэшированной фабрики-молниеносная)
Может быть, я смогу дать еще какой-нибудь совет, если вы скажете мне, какую привязку вы используете и как вы вызываете службу со стороны "клиента" (хотя, может быть, и другую службу). Другая информация, такая как среда хостинга, контекстный режим экземпляра и т. д., Также немного влияет на производительность, о которой вы должны знать-как я уже сказал - Никогда не делайте тесты производительности во время разработки на вашей машине - всегда используйте справочную систему (обычно вы облегчаете отладку, а во время разработки вы размещаете службы на том же компьютере, где выполняется клиентский код), поэтому реальный тест производительности с реальной задержкой сети является обязательным, если производительность критична.
После упоминания всего этого, я должен сказать, что после того, как я сделал много проектов с сервисной архитектурой wcf, я чаще задаюсь вопросом, почему все так быстро, чем почему это "медленно". В конце концов, сервис-это абстракция, и вам всегда приходится платить за это определенную цену, но реальная плохая производительность (по сравнению с прямым вызовом) - это намек на то, что, возможно, что-то "не так" - и shure "глупый" антивирусный пакет (например, forticlient или что-то в этом роде) может иметь негативное влияние - но я бы рассматривал это только в том случае, если производственная среда вынуждает меня сделать это ...(затем создайте исключения или правила для инструмента независимо от того, что)
Я надеюсь, что некоторые из моих мыслей помогут вам.. Счастливое кодирование
С уважением Йоханнес