BasicHttpBinding, ServiceReference из WSDL - проблемы с производительностью

Question

В настоящее время я испытываю некоторые трудности с диагностикой некоторых проблем производительности BasicHttpBinding/ServiceReference. В некоторых случаях при использовании Stopwatch время синхронного вызова метода для службы измеряется как 2,5 секунды. Я выполнил анализ этого же вызова с помощью Wireshark (pcap) и Fiddler (веб-прокси-сервер INET) и получил время отклика 400 мс, что недалеко от лучшего сценария.

Так откуда же возникает это 2-секундное расхождение?

Я использую следующее BasicHttpBinding:

BasicHttpBinding httpBinding = new BasicHttpBinding
    {
        SendTimeout = TimeSpan.FromSeconds(_settings.SendTimeout),
        ReceiveTimeout = TimeSpan.FromSeconds(_settings.SendTimeout),
        MaxReceivedMessageSize = 1024 * 1024 * 100,
        Security =
        {
            Mode = BasicHttpSecurityMode.TransportCredentialOnly,
            Message = { ClientCredentialType = BasicHttpMessageCredentialType.UserName },
            Transport = { ClientCredentialType = HttpClientCredentialType.Basic }
        }
    };

Мы используем эти значения:

ServicePointManager.Expect100Continue = false;
ServicePointManager.DefaultConnectionLimit = 20;
ServicePointManager.MaxServicePointIdleTime = 10000;

а также сжатые HttpWebRequests:

public class CompressibleHttpRequestCreator : IWebRequestCreate
{
    WebRequest IWebRequestCreate.Create(Uri uri)
    {
        HttpWebRequest httpWebRequest = Activator.CreateInstance(typeof(HttpWebRequest),
            BindingFlags.CreateInstance | BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance,
            null,
            new object[] { uri, null },
            null) as HttpWebRequest;

        if (httpWebRequest != null)
        {
            httpWebRequest.AutomaticDecompression = DecompressionMethods.GZip |
                                                    DecompressionMethods.Deflate;
        }

        return httpWebRequest;
    }
}

Я в растерянности относительно того, где может появиться это добавление 2 секунды - я теоретизирую, когда я предполагаю, что запрос или ответ где-то ставятся в очередь, что может задержать запрос, но не уверен, где это может быть?

Запросы выполняются пользовательским интерфейсом / пользователем, и обычно у нас одновременно выполняется только 1-5 запросов, поэтому ServicePointManager.DefaultConnectionLimit из 20 должно быть много. Это происходит с Fiddler и без него, поэтому я исключил все прокси-серверы, повторно использующие соединения и т. Д. Кроме того, установление нового соединения с сервером не могло занять 2 секунды, не так ли?

Обновить:

После дополнительной диагностики я обнаружил некоторые интересные моменты времени при выводе времени трассировки ServiceModel.

Время, от верхнего выделения до нижнего, относится к следующим TraceIdentifiers:

1. http://msdn.microsoft.com/en-GB/library/System.ServiceModel.MessageWritten.aspx (сообщение было написано)
2. http://msdn.microsoft.com/en-GB/library/System.ServiceModel.Channels.MessageSent.aspx (отправка сообщения по каналу)
3. http://msdn.microsoft.com/en-GB/library/System.ServiceModel.Channels.HttpResponseReceived.aspx (получен ответ HTTP)

Я не могу объяснить, почему продолжительность от 1 до 2 может занять более 2 секунд. Есть идеи? Это вообще возможно, что поток отменяется или что-то?