Разрывы строк в Base64 приводят к значительному снижению производительности в Visual Studio - PullRequest
4 голосов
/ 19 августа 2011

У меня есть два разных типа клиентов WCF в моей тестовой среде, которые отправляют файл в службу WCF с помощью операции, подобной следующей, по сравнению с basicHttpBinding:

void SendFile(string filename, byte[] fileBytes) 

Я заметил огромную разницу в производительности. Для точно такого же файла и топологии SendFile занимает менее 1 с на Client1, но занимает около 35-40 с на Client2.

После некоторого перехвата сети я сократил разницу до нескольких разрывов строк в кодированном base64 контенте. Оба клиента отправляют fileBytes в виде текста в кодировке Base64. Однако Client2 так или иначе вставляет много разрывов строк в тексте. Я могу последовательно воспроизвести (используя WFetch), что при прочих равных условиях эти разрывы строк вызывают огромную разницу в производительности.

Сообщение клиента1:

POST /ParkomatService/CommService HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/ICommService/SendFile"
Host: 192.168.10.36
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS .NET CF Web Services Client Protocol 3.5.7283.0)
Cache-Control: No-Transform
Connection: Keep-Alive
Content-Length: 266863


<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><SendFile xmlns="http://tempuri.org/"><filename>test.txt</filename><fileBytes>MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ...(continues)...EyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODk=</fileBytes></SendFile></s:Body></s:Envelope>

Сообщение Client2:

POST /ParkomatService/CommService HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/ICommService/SendFile"
Host: 192.168.10.36
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS .NET CF Web Services Client Protocol 3.5.7283.0)
Cache-Control: No-Transform
Connection: Keep-Alive
Content-Length: 273879

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><SendFile xmlns="http://tempuri.org/"><filename>test.txt</filename><fileBytes>MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2
Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz
NDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkw
MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3
...
(continues)
...
OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1
Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODk=</fileBytes></SendFile></s:Body></s:Envelope>

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

РЕДАКТИРОВАТЬ: С помощью комментария Codo ниже, я заметил, что это различие возникает только при отладке в Visual Studio. Если я запускаю самодостаточный сервис напрямую, то разрывы строк не влияют на производительность. Таким образом, это должно быть проблемой в Visual Studio.

1 Ответ

1 голос
/ 17 февраля 2012

Оказывается, разница в производительности возникает только при запуске службы с подключенным отладчиком Visual Studio. Когда выходил за пределы VS, разница исчезала, и версия с переносами строк имела ту же производительность, что и в других случаях.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...