Подтвердить что ты не робот

WCF намного медленнее, чем WebAPI работает с тем же кодом

В настоящее время у меня есть 2 открытых конечных точки. Первый - это WebAPI (.NET 4.6). Второй - WCF (.NET 3.5). Они оба способны выполнять одни и те же вычисления, однако WCF в среднем в 10 раз медленнее. Рассматриваемый код вычисления содержится в dll, позволяет называть его core.dll. Эта DLL также предоставляет конечные точки WCF и используется сайтом ASP.NET. Webapi dll, позволяет называть его api.dll ссылками core.dll и используется SPA. Расчет может быть инициирован любым клиентом. В среднем, с моими тестовыми данными, служба WCF занимает около 4,5 секунд, чтобы выполнить расчет, когда WebAPI занимает около 450 миллисекунд (или примерно в 10 раз быстрее).

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

Все, что равняется, есть ли какая-то причина, по которой я мог бы видеть эту большую разницу в чистой скорости обработки?

Я на 100% уверен, что данные для обоих клиентов одинаковы, и оба они получают одинаковый результат.

WEBAPI Controller
    Service
        GRAB DATA
        start timer
        Process(DATA) -- the same code/class as below
        end timer
        UPDATE DATA
    Service return
WEBAPI Controller return

WCF Endpoint
    Service
        GRAB DATA
        start timer
        Process(DATA) -- the same code/class as above
        end timer
        UPDATE DATA
    Service return
WCF Endpoint return

EDIT: добавлена ​​диаграмма для ясности (надеюсь)

ИЗМЕНИТЬ 2: Спасибо за ответы/комментарии. К сожалению, это не похоже на то, что из этого вопроса выйдет что-то убедительное. Мы с коллегами в конечном итоге решили поверить, что это просто отличная разница в эффективности версий Framework. Мы закончили реструктуризацию веб-службы, так что расчет происходит только в WebAPI.

4b9b3361

Ответ 1

Использовать профилировщик.

Получите лучшие данные, вне процесса, без всякой хастле. Профиль как для использования ЦП, так и для памяти, коллекций GC, горячего пути и т.д.

Это сказало...

Вы сравниваете две совершенно разные версии .NET. Это делает невозможным проведение справедливого теста.

.NET 4.6 представила новый JIT для 64-разрядной версии значительно быстрее. И это только одно отличие. Слишком много списка.

Если вы не можете изменить версию .NET, вы будете никогда получать точный бенчмарк, но можете искать подозреваемых. Я бы абсолютно использовал профилировщик, но если бенчмаркинг:

Взгляните на сгенерированный IL (pre-JIT), а также убедитесь, что вы тестируете пост-JIT (IL → машинный код).

Один простой способ - просто запустить оба теста один раз (не измеряется) как "холодный старт" перед началом фактического теста.

Другим является использование RuntimeHelpers.PrepareMethod перед эталоном для JIT-методов, чтобы вы не измеряли время JIT.

Конечно, убедитесь, что ваш тест справедлив.

Много информации, но убедитесь, что вы используете таймеры с высоким разрешением, используйте большой размер выборки (повторяйте много раз), Сделайте GC.Collect() перед каждым измерением, используйте одно и то же оборудование (тестирование в том же окне), и т.д.

Правильное выполнение контрольных показателей в процессе (в отличие от профилирования) на самом деле не как легко выглядит.

Все остальное - это просто спекуляция с нашей стороны. Я не мог прокомментировать, если вы разместили реальный код, который бы воспроизводил ваше поведение.

Ответ 2

Мой звонок заключается в том, что вы видите такую ​​разницу, потому что от .net 3.5 до .net 4.6 были большие повышения производительности. Если вы сильно используете элементы структуры, которые могут быть проблемой.

Проверьте ссылки ниже (они содержат информацию об усилении производительности):

Ответ 3

Я думаю, что это комбинация нескольких вещей. А именно, производительность REST (WebAPI) и SOAP (WCF), особенно в зависимости от количества отправляемых/полученных данных. Как и тот факт, что хостинг службы WCF в ASP.NET, я не думаю, что служба действительно запущена или инициализирована до ее вызова, поэтому у вас будет некоторое время инициализации.

Ответ 4

Помимо улучшений производительности, упоминаемых в других ответах здесь, я хотел бы указать очень важное различие между WCF и веб-API:

  • Вы можете получить то же самое от них обоих, но WebAPI предназначен для работы с HTTP (и в основном с JSON) и WCF требуется больше конфигурации для HTTP ( SOAP как обмен сообщениями по умолчанию).
  • WCF имеют поддержку многих видов транспортных протоколов, таких как очередь сообщений, односторонний обмен сообщениями или дуплекс, TCP, HTTP, конечно, и многое другое.
  • WCF может быть сконфигурирован таким образом, что, когда один из вышеперечисленных доступен и быстрее других, его можно использовать как TCP или даже UDP (в более поздних версиях)...
  • Конечно, каждый из этих каналов нуждается в конфигурации, которая иногда может быть болью в шее.
  • WebAPI был разработан для работы с HTTP, поэтому он поддерживает запрос/ответ, заголовки, медиаформаты (текст, JSON, jpeg, XML...), URI, кеширование и многое другое.
  • SOAP обработка и транспортировка "тяжелее", чем JSON. Период. Это основная причина предпочтения JSON над XML за последние 10 лет или около того.
  • Выбирая веб-API, когда ваш сервис может быть доступен для широкого круга клиентов, в основном для браузеров, но также и для мобильных телефонов!
  • WebAPI - это легкая структура, которая хороша для смартфонов с ограниченной пропускной способностью.
  • Как уже упоминалось, клиенты превратились в надежные фреймворки, такие как JQuery, Angular, Android и другие. Все требуют быстрой передачи данных из службы. В настоящее время JSON - самый простой и быстрый способ обработки данных между клиентом и сервером, а WebAPI работает с ним без проблем.

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