Could I know ways to improve performance of my .Net WCF service?
Right now its pretty slow and sometimes it gets clogged & eventually stops responding.
What kind of InstanceContextMode and ConcurrencyMode are you using on your service class?
If it's PerCall instances, you might want to check if you can reduce the overhead of creating a server instance for each call.
If it's Single instances (singleton) - do you really need that? :-) Try using PerCall instead.
Marc
Well, what sort of data are you sending, and over what binding?
Is the problem the size of requests (bandwidth), or the quantity of requests (latency). If latency, then simply make fewer, but bigger, requests ;-p
For bandwidth: if you are sending binary data over http, you can enable MTOM - that'll save you a few bytes. You can enable compression support at the server, but this isn't guaranteed.
If you are using .NET to .NET, you might want to consider protobuf-net; this has WCF hooks for swapping the formatter (DataContractSerializer) to use google's "protocol buffers" binary format, which is very small and fast. I can advise on how on request.
Other than that: send less data ;-p
What binding are you using? If you're using HTTP you could get better perfomance with TCP.
In all likelihood though the bottleneck is going to be higher up in the WCF pipeline and possibly in your hosted objects.
We'd need some more details about your WCF set up to be able to help much.
The symptoms you describe could be caused by anything at all. You'll need to narrow it down by using a profiler such as JetBrain's dotTrace or Automated QA's AQTime.
Or you could do it the old fashioned way by instrumenting your code (which is what the profilers do for you). Collect the start time before your operation starts. When it finishes, subtract the start time from the curren time to determine the elapsed time, then print it out or log it or whatever. Do the same around the methods that this operation calls. You'll quickly see which methods are taking the longest time. Then, move into those methods and do the same, finding out what makes them take so long, etc.
"Improve performance of my .Net WCF service" - its very generic term you are asking, different ways we can improve performance and at the sametime you need to find which one causing performance hit like DB access in WCF methods.
Please try to know available features in WCF like oneWay WCF method it will help you in finding ways to improve performance.
Thanks
Venkat
Here is an article with some statistics from real production systems, you could use these to compare/benchmark your performance.
WCF Service Performance
Microsoft recently released a knowledge base article:
WCF Performance and Stability Issues - http://support.microsoft.com/kb/982897
These issues include the following:
Application crashes
Hangs
General performance of the application when calling WCF Service.
Related
I have an architecture question - related to my ravendb based setup.
I have the following:
ravendb -> wcf service -> (web/iphone/android)
the web/iphone/android level actually has (at the moment - this is growing) connections to 7 wcf services
at the moment the 7 services talk to the same ravendb - this is likely to be segmented in a future refactoring blitz as they don't need to be on the same instance - there is minimal - if none at all - crossover of the model.
My question is this:
I am looking at using memcached - at which points (i have little experience setting this up) can i / should i use memcached?
between ravendb and wcf?
between wcf and (web/iphone/android)?
between all?
am i likely to run into stale data issues? is this taken care of or am i over simplifying things?
As many people will tell you: Premature optimization is the root of all evil (and they are all quoting Donald Knuth I think). So wait when you have performance issues before doing anything (You don't need to wait for the system to crush. Wait till you see 90% utilization of your resources)
That being said, You should use memcached (or any kind of caching for that matter) when you expect to use the cached data before it is being invalidated (The improvement factor will change upon many other factors like: the operation cost and the frequency in which the data accessed)
To answer your "where" questions that really depends where you will be saving most on resources and it is really application specific and can not be answered here.
As an additional pointer, RavenDB REST interface uses ETags to support HTTP-based cahing capabilities. If your HTTP client plays well with those mechanisms, you'll have some nice caching out of the box.
I am not sure how this plays with the WCF stack, though
Currently I am using HttpWebRequest to pull json data from an external site, and the performance was not good. Is wcf much better?
I need expert advice on this..
Probably not, but that's not the right question.
To answer it: WCF, which certainly supports JSON, is ultimately going to use HttpWebRequest at the bottom level, and it will certainly have the same network latency. Even more importantly, it will use the same server to get the JSON. WCF has a lot of advantages in building, maintaining, and configuring web services and clients, but it's not magically faster. It's possible that your method of deserializing JSON is really slow compared to what WCF would use by default, but I doubt it.
And that brings up the really important point: find out why the performance is bad. Changing frameworks is only an intelligible optimization option if you know what's slow, and, by extension, how doing something different would make it less slow. Is it the server? Is it deserialization? Is it network? Is it authentication or some other request overhead detail? And so on.
So the real answer is: profile! Once you know what the performance issue really is, you can make an informed decision about whether a framework like WCF would help.
The short answer is: no.
The longer answer is that WCF is an API which doesn't specify a communication method, but supports multiple methods. However, those methods are normally over SOAP which is going to involve more overheard than a JSON, and it would seem the world has decided to move on from SOAP.
What sort of performance are you looking for and what are you getting? It may be that you are simply facing physical limitations of network locations, in which case you might look towards making your interface feel more responsive, even if the data is sluggish.
It'd be worth it to see if most of the latency is just in reaching the remote site (e.g. response times are comparable to ping times). Or, perhaps, the problem is the time it takes for the remote site to generate and serve the page. If so, some intermediate caching might be best.
+1 on what Isaac said, but one thing I'd add is, if you do use WCF here, it'll internally use the HttpWebRequest in most places, so you're definitely not gaining performance at all. One way you may unintentionally gain in performance -- however -- is in how WCF recycles, reuses, pools, and caches most transport objects internally. So it ultimately goes back to Isaac's advice on profiling.
I have a question. I would like to serve a series of services made with WCF. The client that consumes the services is also .NET with WCF. I would like to have high speed of access, fast response, transport medium to small Data Contracts (primary .net basic data types). The distribution will be over internet, I´m looking for reliability, availability and basic security.
I don´t want to use WsHttp, because my only client is based on .net and I will have almost 150 clients requesting the services.
What do you suggest to use for binding? Are there any disadvantages, risks, etc?
Thanks in advance!
Since you plan to use simple types and small data contracts, the binding you use is nearly irrelevant compared to the latency introduced by going over the Internet. So, the right answer is to use the one which is easiest to manage and the most secure.
I recommend that you host the app in IIS and use a wsHttpBinding and take all the manageability goodness that goes along with it. It will also happen to be interoperable, and while that is irrelevant today, it is just free, so why not?
And, please consider the granularity of your service. You know your customers better, but on the wide open Internet, stuff happens. Because the round trip time over the Internet is variable and impossible to control, it could take milliseconds or seconds or may not get there at all. So, you should take fewer trips with larger payloads if possible, and use all sorts of caching and async operations to make the app appear "fast".
There is a good article on choosing a binding by Juval Lowy here:
http://www.code-magazine.com/article.aspx?quickid=0605051&page=3
Generally the advice is not to use net tcp binding over the internet. Have not heard of anyone doing it. Although it may work if the ports are open all the way and no one blocks the calls.
Test it with nettcp, if it does not work you just need to change the configuration.
The most important thing is to consider your security needs. Do you just need point to point, then basichttp over ssl. Do you need end to end, then wshttp with message encryption.
According to your scenario, NetTcpBinding is the binding of choice. As you are sure that client will be WCF, no need for interoperability.
Have a look here in Programing WCF Services book.
The only thing I'm not sure about is firewalls. If you have to get trough on of theses, maybe some WS binding could be more appropriate.
What is the best practice around implementing WCF proxy pooling? What precautions should be taken in the design?
Any pointers in this direction is greatly appreciated.
If you want to go down that path, from Performance Improvement for WCF Client Proxy Creation in .NET 3.5 and Best Practices:
You need to implement the right
synchronization logic for managing the
proxies.
You need to make sure the
proxies are used equally. Sometimes,
you may want to implement a
round-robin pattern for the proxies.
You need to handle
exceptions and retries for the pool.
The pool size needs to be
limited and configurable.
You may need to be able to
create proxies even if when no proxy
is available from the pool.
Why do you want to pool proxies?
Pools usually only exist when a resource (like a database connection) is scarce, expensive to build and possibly costly to maintain.
This should not be the case with WCF proxies, really - you create them as needed, and discard them when no longer needed.
I don't see any benefit or real use in trying to pool WCF proxies - what problem or issue are you trying to solve?
OK, thanks for your reply - I do understand what you're trying to accomplish - but I'm afraid, you're pretty much on your own, since I don't think there's any bits and pieces in the .NET framework and/or the WCF subsystem to would aid in creating proxy pools.
Marc
PS: as the article that Tuzo linked to shows, maybe you can get away with just caching the channelFactory objects. Creating those is indeed quite expensive, and if you can cache those for the lifetime of the app, maybe that'll be good enough for your needs. Check it out!
I am using basic HTTP binding.
Does anybody know which is the best binding in terms of performance as thats the key issue for our site?
Depends on where the services are located.
If they're on the same machine, NetNamedPipeBinding should give you the maximum performance.
Otherwise you'll have to choose depending on where they are located, if they have to communicate over the internet, interopability etc.
Soledad Pano's blog has a good flow chart to help with choosing the appropriate bindings depending on situation
This is comparing apples to oranges. If you are using the basic HTTP binding, then there is a basic set of services and whatnot that it is providing, which is different from the services that the WsHttpBinding offers, for example.
Given that, the performance metrics are going to be different, but you also aren't going to get the same functionality, and if you need that particular set of functionality, then the comparison isn't worth doing at all.
Additionally, there are bindings (like the net tcp and named pipe bindings) which might not be applicable at all, but have better performance characteristics.
Finally, your statement about "best performance" indicates that you really aren't looking at it the right way. You have expectations of what your load is during peak and non-peak times, as well as the response times that are acceptable for your product. You need to determine if WCF falls within those parameters, and then work from there, not just say
"I'm looking for the best performance".
You will have to give more requirements for what you are trying to do, and then more light can be shed on it.
A good resource for WCF info:
http://www.codeplex.com/WCFSecurity/Wiki/View.aspx?title=Questions%20and%20Answers&referringTitle=Home
Has a section on choosing bindings for your particular scenario. Is security not an issue? If not then you have more choices available to you.
It's hard to tell what the performance will be without other known factors (server HW, amount of concurrent users, etc.).
HTTP binding will be performing slightly better then HTTPS for example, but binary WCF to WCF communication will be quicker then HTTP for the price of lesser compatibility.
I think you need to provide more details - what is the desired functionality (do you need SOAP messages exchange, or Ajax with JSON?) and expected server load.