Timeout Considerations for Solicit Response – Part 2
- by Michael Stephenson
To follow up a previous article about timeouts and how they can affect your application I have extended the sample we were using to include WCF. I will execute some test scenarios and discuss the results.
The sample
We begin by consuming exactly the same web service which is sitting on a remote server. This time I have created a .net 3.5 application which will consume the web service using the basichttp binding. To show you the configuration for the consumption of this web service please refer to the below diagram.
You can see like before we also have the connectionManagement element in the configuration file.
I have added a WCF service reference (also using the asynchronous proxy methods) and have the below code sample in the application which will asynchronously make the web service calls and handle the responses on a call back method invoked by a delegate.
If you have read the previous article you will notice that the code is almost the same.
Sample 1 – WCF with Default Timeouts
In this test I set about recreating the same scenario as previous where we would run the test but this time using WCF as the messaging component. For the first test I would use the default configuration settings which WCF had setup when we added a reference to the web service.
The timeout values for this test are:
closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
The Test
We simulated 21 calls to the web service
Test Results
The client-side trace is as follows:
The server-side trace is as follows:
Some observations on the results are as follows:
The timeouts happened quicker than in the previous tests because some calls were timing out before they attempted to connect to the server
The first few calls that timed out did actually connect to the server and did execute successfully on the server
Test 2 – Increase Open Connection Timeout & Send Timeout
In this test I wanted to increase both the send and open timeout values to try and give everything a chance to go through.
The timeout values for this test are:
closeTimeout="00:01:00" openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00"
The Test
We simulated 21 calls to the web service
Test Results
The client side trace for this test was
The server-side trace for this test was:
Some observations on this test are:
This test proved if the timeouts are high enough everything will just go through
Test 3 – Increase just the Send Timeout
In this test we wanted to increase just the send timeout.
The timeout values for this test are:
closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:10:00"
The Test
We simulated 21 calls to the web service
Test Results
The below is the client side trace
The below is the server side trace
Some observations on this test are:
In this test from both the client and server perspective everything ran through fine
The open connection timeout did not seem to have any effect
Test 4 – Increase Just the Open Connection Timeout
In this test I wanted to validate the change to the open connection setting by increasing just this on its own.
The timeout values for this test are:
closeTimeout="00:01:00" openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
The Test
We simulated 21 calls to the web service
Test Results
The client side trace was
The server side trace was
Some observations on this test are:
In this test you can see that the open connection which relates to opening the channel timeout increase was not the thing which stopped the calls timing out
It's the send of data which is timing out
On the server you can see that the successful few calls were fine but there were also a few calls which hit the server but timed out on the client
You can see that not all calls hit the server which was one of the problems with the WSE and ASMX options
Test 5 – Smaller Increase in Send Timeout
In this test I wanted to make a smaller increase to the send timeout than previous just to prove that it was the key setting which was controlling what was timing out.
The timeout values for this test are:
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:02:30"
The Test
We simulated 21 calls to the web service
Test Results
The client side trace was
The server side trace was
Some observations on this test are:
You can see that most of the calls got through fine
On the client you can see that call 20 timed out but still hit the server and executed fine.
Summary
At this point between the two articles we have quite a lot of scenarios showing the different way the timeout setting have played into our original performance issue, and now we can see how WCF could offer an improved way to handle the problem. To summarise the differences in the timeout properties for the three technology stacks:
ASMX
The timeout value only applies to the execution time of your request on the server. The timeout does not consider how long your code might be waiting client side to get a connection.
WSE
The timeout value includes both the time to obtain a connection and also the time to execute the request. A timeout will not be thrown as an error until an attempt to connect to the server is made. This means a 40 second timeout setting may not throw the error until 60 seconds when the connection to the server is made. If the connection to the server is made you should be aware that your message will be processed and you should design for this.
WCF
The WCF send timeout is the setting most equivalent to the settings we were looking at previously. Like WSE this setting the counter includes the time to get a connection as well as the time to execute on a server. Unlike WSE and ASMX an error will be thrown as soon as the send timeout from making your call from user code has elapsed regardless of whether we are waiting for a connection or have an open connection to the server. This may to a user appear to have better latency in getting an error response compared to WSE or ASMX.
