locked
Webservice first call slow in C# RRS feed

  • Question

  • I have a .NET and a Java webservice that I connect to in C#.  I used the webreferences to build all the code.  When I call the webservice call it takes 4 seconds on the first call and all future calls within the application takes .10 seconds.  However if I do not use c# and use another programming language and use the SoapToolkit I do not experience this 4 second first call delay.

     

    I have tried setting the proxy property to null but no effect.  Any help in why c# takes 4 seconds on the first webservice call would be great. 

     

    Thanks,

     

    Keith Sobolewski

    Friday, August 31, 2007 4:35 PM

Answers

  • Why did you set the Proxy property to null? Was it because you had read other posts here that mentioned proxies as a potential source of a slow start?

     

    If so, then you missed the main point of those posts. The problem wasn't with the Proxy property in the client, but rather with the default proxy settings configured for Internet Explorer. These defaults are often configured by your IT organization by using Group Policy.

     

    You need to use a tool like Microsoft Network Monitor or the TcpTrace tool from www.pocketsoap.com to look at the traffic between client and server when this problem occurs. You will see whether, for instance, the delay is due to automatic proxy setting, or some other network traffic that happens "only once".

     

    The Soap Toolkit version of the code may be configured to not use a proxy at all, or to only use a proxy configuration that does not require auto-configuration, or it may be different in any number of other ways. By watching both the .NET network traffic and the Soap Toolkit network traffic, you will be able to compare them and determine wht's different between them.

     

    It is unlikely that the difference is C#.

    Saturday, September 1, 2007 11:42 PM
    Moderator
  • Keith, I notice that the .NET version expected 100-continue. Did it receive a 100-continue?

     

    Also, I notice that the content-length is different. Was the difference in the content significant?

     

    The differences may not be in the first packet that was sent; it may be in the interaction that follows that first packet.

     

    Wednesday, September 5, 2007 4:29 PM
    Moderator
  •  

    Which version of the .NET Framework are you using?

     

    Is the first call the same as the subsequent call?

     

    Another possibility is that it's creating the XmlSerializers for the web service (although 4 seconds seems a little bit high).

    Wednesday, September 5, 2007 6:00 PM
    Moderator
  • Please try enabling Network Tracing with timestamps using the following instructions:

    http://msdn2.microsoft.com/en-us/library/ty48b824.aspx

     

    The trace will have detailed information about what is happening at the networking layer, which should enable you to figure out what is taking up all of the time.

     

    Daniel Roth

    Monday, September 10, 2007 7:32 PM
  • After looking at both the TCP trace and the network tracing it is obvious that it is not on the network layer.  The network round trip is only taking .30 seconds.  Using logging in the application giving system time down to the milliseconds comparing to the TCP trace when it see's it hit the network and the network trace logs that the overhead in the .NET call is in overhead prior to making the soap call. In release mode vs debug mode there is a .50 seconds difference in the post call probably for xml to be serialized.

     

     

    Tuesday, September 11, 2007 3:42 PM

All replies

  • Why did you set the Proxy property to null? Was it because you had read other posts here that mentioned proxies as a potential source of a slow start?

     

    If so, then you missed the main point of those posts. The problem wasn't with the Proxy property in the client, but rather with the default proxy settings configured for Internet Explorer. These defaults are often configured by your IT organization by using Group Policy.

     

    You need to use a tool like Microsoft Network Monitor or the TcpTrace tool from www.pocketsoap.com to look at the traffic between client and server when this problem occurs. You will see whether, for instance, the delay is due to automatic proxy setting, or some other network traffic that happens "only once".

     

    The Soap Toolkit version of the code may be configured to not use a proxy at all, or to only use a proxy configuration that does not require auto-configuration, or it may be different in any number of other ways. By watching both the .NET network traffic and the Soap Toolkit network traffic, you will be able to compare them and determine wht's different between them.

     

    It is unlikely that the difference is C#.

    Saturday, September 1, 2007 11:42 PM
    Moderator
  • Yes I tried everything with proxy including making sure the local internet setting wasn't using any proxy since it was calling an internal system. No effect.  I have ran the tcptrace and there really isn't any differences between the two packets accept time it takes for the .NET version to make the request.  Below is the only differences between the two packets.

     

    .NET packet setting:

    User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.832)
    Content-Type: text/xml; charset=utf-8

    Content-Length: 330
    Expect: 100-continue
    Connection: Keep-Alive

     

    Soap Toolkit packet information:

    Content-Type: text/xml; charset="UTF-8"
    User-Agent: SOAP Toolkit 3.0
    Content-Length: 434
    Connection: Keep-Alive
    Cache-Control: no-cache
    Pragma: no-cache

     

     

    Wednesday, September 5, 2007 3:49 PM
  • Keith, I notice that the .NET version expected 100-continue. Did it receive a 100-continue?

     

    Also, I notice that the content-length is different. Was the difference in the content significant?

     

    The differences may not be in the first packet that was sent; it may be in the interaction that follows that first packet.

     

    Wednesday, September 5, 2007 4:29 PM
    Moderator
  •  

    Which version of the .NET Framework are you using?

     

    Is the first call the same as the subsequent call?

     

    Another possibility is that it's creating the XmlSerializers for the web service (although 4 seconds seems a little bit high).

    Wednesday, September 5, 2007 6:00 PM
    Moderator
  • I have built the project for release mode so that it built the xmlserializer dll with it.  It got it down to 3.5 seconds.  Also the packet looks the same for all proceding calls.  The difference in packet out size is because the .net framework has the mozilla line instead of the soaptoolkit.  I am using the .NET 2.0 framework. 

    Monday, September 10, 2007 2:15 PM
  • So, Keith, are you saying that in the .NET version, even though it sent a "Expects: 100-continue" header, it did not receive a "100-continue"? That there was no "continue" exchange?

     

    Monday, September 10, 2007 2:48 PM
    Moderator
  • Please try enabling Network Tracing with timestamps using the following instructions:

    http://msdn2.microsoft.com/en-us/library/ty48b824.aspx

     

    The trace will have detailed information about what is happening at the networking layer, which should enable you to figure out what is taking up all of the time.

     

    Daniel Roth

    Monday, September 10, 2007 7:32 PM
  • After looking at both the TCP trace and the network tracing it is obvious that it is not on the network layer.  The network round trip is only taking .30 seconds.  Using logging in the application giving system time down to the milliseconds comparing to the TCP trace when it see's it hit the network and the network trace logs that the overhead in the .NET call is in overhead prior to making the soap call. In release mode vs debug mode there is a .50 seconds difference in the post call probably for xml to be serialized.

     

     

    Tuesday, September 11, 2007 3:42 PM