I have defined nothing in my configuration for WCF scaling. I'm targetting .NET 4.0, and I believe the main configuration I need to be aware of is MaxConcurrentCalls as the default is 16.
The services haven't had their behavior changed - they are instance per call by default.
The services don't maintain any state and act as a facade to a more complex system. WCF is running under an IIS host and using either basicHttpBinding or wsHttpBinding (both are in use, but not at the same time).
Do I need to increase anything other than the maximum concurrent calls?
What happens when you get the 17th concurrent call - is it queued (can't see answer on MSDN) or is it dropped?
Do I need to worry about setting values for MaxConcurrentInstances and MaxConcurrentSessions based on the above information?
Related
Questions:
Why information on this subject are so poor?
Nobody uses WCF transaction services?
In this production environment is only allowed to use the ports 80 and 443, WCF tranaction technology uses other ports?
This technology is interoperable in any way? Client Java server .NET C#?
I am using WCF transaction to ensure complete communication between the client and the service. There is another way to ensure this without using WCF Transaction?
I appreciate any help and thanks
Why information on this subject are so poor?
Because no-one in their right minds wants to do transactional service calls over port 80 on the public web unless there is no other option (including suicide).
Nobody uses WCF transaction services?
See answer to the previous question.
In this production environment is only allowed to use the ports 80 and
443, WCF transaction technology uses other ports?
No, WCF transactions are an implementation of WS-Atomic Transaction, which uses port public ports. This was originally part of the SOAP 1.2 standard.
This technology is interoperable in any way? Client Java server .NET C#?
In theory yes because it's based on a standard which, as long as it's implemented correctly, should be interoperable with any other correct implementation. However, in practice, standards are almost impossible to implement uniformly and so I would seriously doubt that .net and java implementations would just work with each other (they're rarely able to interop over SOAP 1.1 even).
I am using WCF transaction to ensure complete communication between
the client and the service. There is another way to ensure this
without using WCF Transaction?
It depends on what you mean by complete communication. Complete meaning 100% ACID? That doesn't exist. What if the world blows up?
So 99.99% ACID? This level of completeness (1 failure per 10,000 calls) can be achieved without using any transactions at all. This is the normal operating range I would expect to see from a well-designed service-consumer interaction.
If you require a higher completeness rating you could have the service expose a recovery or rollback operation, so the consumer can take the appropriate action and rollback any calls made previously to a failed call. Such an approach is known as a compensation pattern.
Can someone help to what are the major diff between netTcpBinding v/s BasicHttpBinding ?
In my current project we convert BasicHttpBinding to netTcpBinding and get performance issue, it start timing out even thou the value in BizTalk is set to 1:00:00. We couldn't figure out why ?
netTcp and basicHttp bindings use entirely different transport mechanisms: TCP instead of HTTP. In theory, the binary encoding of TCP should be faster than the text encoding of HTTP.
As discussed here, netTcpBinding may not be as fast, because of additional security overhead and/or contention:
By default, NetTcpBinding enables certain levels of security add
overhead to the message processing pipeline of the WCF runtime.
Additionally, the NetTcpBinding also enables the port sharing feature
which means that your WCF host won’t have exclusive access to the port
and instead might share it with other applications. This might get
very interesting if you are hosting your service in a Windows Server
2008 or Windows 7 environment given that there are a number of Windows
applications that rely on NetTcpBinding endpoints. Finally, the
default values for theListenBacklog and MaxConnections settings are
set to 10 which is far from optimal for a large number of clients.
Also note that without more information on what part of communication is timing out, it's difficult to say the exact cause. Remember, each side of the transaction has different timeout settings for Open, Close, and Send or Receive.
I have already asked a similar question here: WCF Service calling an external web service results in timeouts in heavy load environment but I've got a better idea now as to what's happening so posting a new question.
This is what is happening:
.NET client sends multiple requests at the same time to a WCF service (if it helps - I'm replicating this scneario by using Visual Studio Load Tests)
The client has got a "sendTimeout" set to 5 seconds
The WCF service receives it and start processing it. The processing involves sending a request to an external service which could take about 1 second to come back with a response
This is where I think the problem is: the client has sent many requests to the service and since the service is still busy processing the concurrent requests, some of the reqeusts from the client are timing out after 5 seconds
I have tried the following:
Changed the InstanceContextMode to PerCall
Increased the values of maxConcurrentCalls & maxConcurrentInstances
Increased the value of connectionManagement.maxconnection in machine.config
But none of that seems to be making any difference. Does anyone has any idea how can I ensure that I don't run into this timeout issue?
OK, you say WCF and that is not enough. What binding are you using and where are you hosting it? If you are using IIS, the could be different underlying problem than self-hosting.
The likely reason is the small number of ThreadPool size. You can use ThreadPool.SetMaxThreads() to change this but beware this is a sensitive value. Have a look here.
Check out the following link:
http://weblogs.asp.net/paolopia/archive/2008/03/23/wcf-configuration-default-limits-concurrency-and-scalability.aspx
I'm not sure what you're trying to achieve. Since the WCF service is doing a time consuming operation, you can't overload it and expect it to function. You can do the following (check the link about to set the following):
Increase the receiving capacity of the wcf service
Increase the send timeout of the service
Increase the send timeout of the client
Increase the receive timeout of the client
Limit the outgoing connections to the wcf service
The best and most robust option would be to configure and use MSMQ with the WCF service.
My last experience with WCF 3.0 was pretty bad, because of this I reverted to using ASMX. I now see that WCF 4.0 seems to provide a better configuration model, my only concern is that with WCF 3.0 I had a lot of timeouts on extended service calls, however with asmx these timeout values can be configured through IIS and also accept the negative integer value of -1.
Does WCF 4.0 default configuration support getting timeout values from IIS, or once again do you need to configure the timeouts to handle extended web service calls that take time to complete (could be up to 6 hours).
Thanks
In WCF you have configuration level control over timeouts on both servers and clients by editing the binding configuration. Since WCF was not designed to be coupled with IIS I don't think you can inherit the timeouts from IIS so you might have to set them in both places.
Check this link for the documentation on the basicHttpBinding element (which is used for SOAP 1.1): http://msdn.microsoft.com/en-us/library/ms731361.aspx
And this one for details on different timeout configurations in WCF: http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/84551e45-19a2-4d0d-bcc0-516a4041943d/
I have personally used the timeout configurations in different .Net 3.5 projects and they worked for me.
WCF by nature is transport agnostic so the configuration has to accommodate for transport types not having timeout.
Problem in HTTP is if you have one timeout for HTTP and one explicitly for the WCF, there will be a conflict and that is why you have to define them separately.
I believe WCF is a big fudge, an being transport agnostic causing performance degradation while easing with deployment and configuration. Having said that, I think it is far superior to ASMX, IMHO :)
In my application I need to push notifications of real time events from server to clients. The amount of data to pass is very small, mostly and Id. The number of clients listening simultaneously can be around 100 and I may have to publish one notification every 2 - 3 seconds. Both the server and client are built using .Net and WCF.
Given these requirements I have built a set of WCF services which will be run on a load balanced server cluster. The Instance context mode is Per Call and there is no need for sessions etc.
I am currently using BasicHttpBinding. Will TCP binding be better? Does it run on IIS 5 or 6? If not why?
What configuration for serialization can work best?
What are the things I need to do to make sure I get maximum performance?
Edit - Adding more information based on some of the responses -
I host a small WCF service in the client process using manual hosting. The server just calls this service on each client to push the data to all of them.
Firstly have you considered using messaging for what you are trying to achieve?
In answer to will TCP binding work better than BasicHttpBinding- almost certainly yes. If you want to use TCP, you can't use IIS- look into WAS with Windows Server 2008. If you're stuck with Windows Server 2003, then you'll have to host in a windows service instead.
You've made a good choice by choosing per call- this is the preferred instance management mode for creating scalable WCF services.
Edit:
Now you've update your question, I recommend you take a look at IDesign's Pub/Sub framework if you want to stick with WCF. I'd also look at Pub/Sub with MSMQ in WCF and also with "Vanilla" products such as Tibco RV.
If you need pushing data from service to clients you need sessions and you need duplex binding - NetTcpBinding or WSDualHttpBinding. It will not work with BasicHttpBinding because it allows only pulling data (client pools the service for changes). Push data means tha service sends data to clients when needed.
NetTcpBinding always crete session. It can't be hosted in IIS 6 or older. NetTcpBinding is allowed only in Windows Activation Service (WAS) which is extension of IIS 7.x. For older systems you need self hosting = windows service.
Edit:
Based on your description you need Publish-Subscribe message exchange pattern.