I have added reference to WCF Service in my client asp.net website.
Right now, I am just instantiating WCF Service at every service method call as:
TemplateServiceClient objTemplateService = new TemplateServiceClient();
objTemplateService.MethodCall();
I am not sure about the performance down due to above.
If it is going to be a performance hit, Can you suggest me a better approach to call my service methods.
Thank you!
The only way to know about performance is to test it, so if you've any concerns, you should do that.
It's hard to know without knowing what you're doing and how it will be used.
A web service client is just another object so you can do all the usual things:
what you're doing with a new instance every time;
reuse the object if the service calls are in the same method;
create the object as a field within your class;
singleton
Personally, I tend to end up with the second for most things I do but that fits my usage profile.
As long as the performance is acceptable, it's not a problem. Don't over-optimize prematurely without even knowing whether there indeed IS a performance problem or not...
Measure your performance, and see, if it is.
The per-call scenario is indeed the preferred and recommended scenario for WCF - it just works best that way, no hairy mess with stateful services, sessions or singleton - it just works and scales quite well to even fairly heavy loads.
Related
I'm using a named-pipe WCF service, which has about 1000 methods (yes, I know it's not a good practice, but it's life...).
The problem I got is that when starting up the WCF service, it costs about 10 seconds on constructor of ServiceHost class. By tracking into it, I found the time is spent on preparing service description (InitializeDescription method of ServiceHostBase class). I guess it's because there are too many methods defined in this service contract.
Anyone can help to answer how can I speed up the start up time of this big service contract?
I know it's not a good practice to define so many methods in one service contract. But I can't change the service contract (such as divide it to several smaller ones). You know, this is the real life...
Thanks.
Refactoring this endpoint, while non-trivial, is probably fairly easy to do if you manage the process properly:
Pick a single logical business case which your endpoint currently supports.
Create a list of all the operations needed to fulfil this single logical business operation.
Create a new endpoint for just those operations, keeping the same operation signatures.
Re-point any existing consumers who want to fulfil this business case to the new endpoint.
Repeat process until you have covered all business cases.
Apologies this does not address original question directly and appreciate re-working on this scale may be outside the scope of your current development.
I have a WCF web service that implements a RESTful interface. We're using the InstanceContextMode of PerCall, and are looking for options to use for caching objects for reuse on subsequent calls.
We're looking to override/extend the WCF Context logic in order to create/maintain/clean up objects to be shared among implementation methods of a PerCall service interface.
I'd also like to see a diagram of the objects created/used during a call to a WCF interface. I have a very nice one for ASP.Net event calls, but I haven't found anything for WCF. I'm not sure which classes to override or interfaces to implement to interject my own logic into the WCF call hierarchy for persisting objects between calls.
If you are looking for events happening, this is a must read - there are very nice diagrams there as well.
Objects created very much depend on your configuration. With WCF REST, I imagine it must be small.
If I were you, I would not go down the route of caching and solving a problem that does not exists - or at least I assume so from your question. PerCall is the only scalable setting. Also I imagine a REST service would be designed as stateless anyway.
I believe Jimmy Nillson said he generally made his webservices singletons. Is this the preferred method, and with WCF? Other than making the service methods static, is there something else to be done?
good responses, but I think there is a problem in the original question. "Typical use" of a technology is a poorly formed question. No one has a "typical" scenario, and you should review the requirements of your particular problem before deciding on an implementation or approach. Your requirements should inform your solution.
For instance, Singletons [ie the Singleton pattern] is just another tool in our box, and like any tool, there are cases where it works, and others it does not. Specifically, if you need to centralize business logic [more applicable in a standalone application than a remote WCF service], or share memory or a resource, a Singleton works well. Of course, if you are sharing business logic, state is maintained in the call stack, and multi threading is moot. If sharing memory between consumer calls, then multi threading is an issue. As regards WCF, there are two modes [actually three, but the third is a special case of the first] of multi-threading behaviour you can specify,
// we are specifying that this service implementation is single-threaded
// and WCF should permit *at most* one call at a time. Any requests made
// simultaneously/concurrently are queued.
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]
public class SingleThreadedNonThreadSafeService : IService { ... }
and
// we are specifying that this service implementation is multi-threaded
// and [hopefully!] thread-safe. WCF should permit any number of threads,
// or any number of simultaneous concurrent calls.
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]
public class MultiThreadedThreadSafeService : IService { ... }
The Xml comments for ConcurrencyMode basically say the same thing as above.
If you DO NOT need to share business logic or memory between consumers, then DO NOT use a Singleton, the "model" DOES NOT fit the problem. It's like forcing a glass slipper on a step-sister's foot! And no one should ever have to see that.
Conversely, if no state is shared between calls, host an instance per-call\session.
Typically NOT. Singletons are a mess, since to make them perform well, you'll need to make them multi-threaded, and that's just asking for trouble unless you really really really know what you're doing.
The best practice for WCF is to use per-call instantiation - each request gets its own copy of the service class, no multi-threading worries, good performance - store anything that needs to persist in a database - works like a charm.
The only real scenario where singleton might make sense is if you have to have all service request be using/handled by a physical resource that's available only in a single instance - if your singleton service serializes and thus protects a single resource, then it makes sense to use it.
Otherwise - spare yourself the trouble! :-)
Singleton WCF services should hardly ever be used- Singletons are the enemy of scalability! They only make sense in weird scenarios- logging to a single file, a single communications port or hardware device.
As Marc says the best choice for scalability with WCF is per call services (they offer the best trade off between performance and scalability). Per call services also work very well with load balancing.
I need to hook into the WCF operation process to execute some code right before and right after each operation.
Some context:
I already have a custom servicehost, servicehostfactory and servicebehavior
all my services are based on a common base class
I've been snooping around and I think using a IParameterInspector would be the best choice, but I'm not entirely sure given that the code I need to execute has nothing to with parameters...
Any clues?
IParameterInspector is not a bad choice.
Do you need to know which operation/session/endpoint is happening, or are you just installing the same logic for all operations? Do you need to modify the Message object? (These considerations may change your choice of extensibility point.)
Do you need to modify thread-local storage? If so, prefer ICallContextInitializer.
I'm looking to push my domain model into a WCF Service API and wanted to get some thoughts on lazy loading techniques with this type of setup.
Any suggestions when taking this approach?
when I implemented this technique and step into my app, just before the server returns my list it hits the get of each property that is supposed to be lazy loaded ... Thus eager loading. Could you explain this issue or suggest a resolution?
Edit: It appears you can use the XMLIgnore attribute so it doesn’t get looked at during serialization .. still reading up on this though
Don't do lazy loading over a service interface. Define explicit DTO's and consume those as your data contracts in WCF.
You can use NHibernate (or other ORMs) to properly fetch the objects you need to construct the DTOs.
As for any remoting architecture, you'll want to avoid loading a full object graph "down the wire" in an uncontrolled way (unless you have a trivially small number of objects).
The Wikipedia article has the standard techniques pretty much summarised (and in C#. too!). I've used both ghosts and value holders and they work pretty well.
To implement this kind of technique, make sure that you separate concerns strictly. On the server, your service contract implementation classes should be the only bits of the code that work with data contracts. On the client, the service access layer should be the only code that works with the proxies.
Layering like this lets you adjust the way that the service is implemented relatively independently of the UI layers calling the service and the business tier that's being called. It also gives you half a chance of unit testing!
You could try to use something REST based (e.g. ADO.NET Data Services) and wrap it transpariently into your client code.