Ускорить запрос SOAP в C#

Question

У меня есть кусок кода, как это:

foreach (var e in foobar) 
    { 
     var myObj = new MyObj(); 

     GenericResult res = soapClient.doSomething(e); 
     if(res.success == true){ 
      myObj.a = e.a; 
      myObj.b = e.b; 
     } 
    } 

Каждый SOAPRequest занимает около 500 миллисекунд, а иногда foobar это элементы так 1000+ я тратить много времени на ожидание ответ soapClient. Я пробовал использовать Parallel.ForEach, но он не работает, потому что поставщик SOAP принимает только сериализованные запросы. Поставщик предлагает использовать async звонки, такие как soapClient.doSomthingAsync Проблема заключается в том, что мне нечего делать, пока я не получил ответ soapClient.

Единственное решение, которое я имею в виду, использую Parallel.ForEach и lock в мыльном вызове

Answer 1

Всего несколько вещей, которые вы можете попробовать.

• Какой тип аутентификации применяется к вызову службы. Если служба и т. Д. Аутентифицируется против AD, вы должны убедиться, что только первый вызов аутентифицирован, а остальные вызовы просто контрейлерные. Аутентификация AD может занять значительное время (0,3 - 1,0 с)

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

• Вы пытались выполнить команду ping на сервере, на который вы нацелились, - приемлемы ли таймеры пинга ?.

• Сколько времени тратится на первый вызов по сравнению со следующими вызовами. Первый вызов всегда будет занимать значительное количество времени, так как среда выполнения CLR должна генерировать нагрузку на лодку динамического XML-кода. Простое создание JIT-кода XmlSerializer является дорогостоящим, поскольку оно динамически генерирует код C#, удары компилятора CSC и загрузку сгенерированной DLL. Вы можете посмотреть на инструмент SGEN, что делает возможным генерировать XmlSerializer библиотек во время компиляции и вместо выполнения (обратите внимание, что это поможет только на первых таймингах исполнения)

Я не могу видеть сколько времени на самом деле тратится на стороне сервера, внутри выполнения doSomething(), поэтому трудно понять, сколько времени фактически тратится на сеть. Неисправное сетевое оборудование, кабели, коммутаторы, а также брандмауэры, таблицы маршрутизации, SLA и т. Д. Могут негативно повлиять на то, какую производительность вы можете извлечь из этого.

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