I'm building web application (in this context the client) which talk with a different process (in this context the server) through a namedpipe wcf service (WCF 4).
After reading many articles I was thinking to create a pool of proxy connected to the server (I've read it provide better performance) used in roundrobin.
Each call will be very short, on the server i need to reads and writes simple properties on few objects but this objects are shared so i must use locks in any case.
I expect very high concurrency.
Beacuse of the pool, the client will have N session always open with server.
I was wondering what should be the best settings for InstanceContext-ConcurrencyMode between PerSession-Single or SingleInstance-Multiple.
Thank You
My opinion: Do not use custom pool of proxies. Use build-in pooling of connections. You can't fully control connectionPooling in predefined bindings but you have full control in customBinding when using namedPipeTransport.
From implementation perspective in your client - use new proxy for each client's request. Don't share proxies among requests.
Related
I have a question with regards to WCF client channel lifetime while using Message security, but first, a few notes on my company's setup and guidelines:
Our client-server applications are solely for intranet use
Our clients are WPF applications
Our company's guidelines for WCF usage are:
Use wsHttpBinding
Use Message Security
Service InstanceMode: PerCall
Service ConcurrencyMode: Multiple
It is the first time I have to use message security on an intranet setup. Here's how I typically use my client channels to limit the amount of resources kept on the client and server and literally just to keep things simple:
Instantiate + open channel (with ChannelFactory)
Make the WCF call
Close / dispose the channel asap
While monitoring this strategy with Fiddler 2, I noticed that because of Message Security, a single WCF call ended up causing 5 round-trips to my service:
3 initial round-trips for handshaking
1 round-trip for the actual WCF call
1 call to close the session (since I am using PerCall, I am assuming this is more a security session at the IIS level)
If I were to turn off Message Security, as one would expect, one WCF ended up being... A single round-trip.
As of now, I must use Message Security because that's our guideline. With this in mind and knowing that we make hundreds of WCF calls from each client WPF app a session, would you therefore advise to open the client channel and keep it open for re-use instead of disposing of it every time?
I would advise not to preemptively turn off features until you know they are a known problem. Preoptimization is needless work. Until you notice your clients having lagging problems, I would not worry about the message security. At that point, try a few things: one of your approaches of keeping a client open longer; two, try grouping requests together without turning off message security; three, consider caching, if you can; four, if the message security is the final culprit, then try a different method. I wouldn't just turn something off because I see a bit more network traffic until I knew it was the absolute last thing that I could do to improve performance.
I've got a working Silverlight/WCF application that I need to start thinking about scaling. An obvious target for scaling, of course, is Azure.
The key architectural feature of the application is that 2-10 Silverlight clients will join a given "room" (using a duplex Net.TCP connection), and any of those clients can then send a message (for instance, a chat message), which then needs to be pushed in real-time to every other client connected to the same room, using the underlying duplex WCF connection.
Right now, the way the WCF service works is basically to keep in-memory a list of sessions and the rooms that they're associated with, so that when a message from one session comes in, it can automatically send the message to every other session in the room.
This works fine for a single WCF server instance, but it gets complicated if you need to scale it so that multiple WCF instances are in play. If you use network-layer load balancing, of course, you would typically find that only some of the members of your room are on the same server you're on, which means that when it comes time to push out messages to all those members, only some of them would actually get notified.
Apart from Azure, I had been thinking that I would handle it via some sort of application-layer load balancing. For instance, the web server that each client downloads the Silverlight application from might do a primitive round-robin sort of load-balancing, i.e., "OK, everyone in room x, you use WCF instance 1. Everyone in room y, you use WCF instance 2." That sort of thing.
So I have two questions:
(1) Is there any other, better way to architect this, so as to be able to use network-layer load balancing rather than needing to make the application aware of the underlying infrastructure?
(2) If I have to do the application-layer load balancing, what's the best way to handle this in Azure? Do I have to use the IAAS (full VM's), or is there a way to do this using PAAS (worker roles)? My understanding is that it's not possible to independently address worker roles, which would make a roles-based approach difficult, if not impossible.
SignalR powered by the Azure Service bus, may work for you.
http://vasters.com/clemensv/2012/02/13/SignalR+Powered+By+Service+Bus.aspx
I have asp.net site where I call my WCF service using jQuery.
Sometimes the WCF service must have an ability to ask user with confirmation smth and depend on user choice either continue or cancel working
does callback help me here?
or any other idea appreciated!
Callback contracts won't work in this scenario, since they're mostly for duplex communication, and there's no duplex on WebHttpBinding (there's a solution for a polling duplex scenario in Silverlight, and I've seen one implementation in javascript which uses it, but that's likely way too complex for your scenario).
What you can do is to split the operation in two. The first one would "start" the operation and return an identifier and some additional information to tell the client whether the operation will be just completed, or whether additional information is needed. In the former case, the client can then call the second operation, passing the identifier to get the result. In the second one, the client would again make the call, but passing the additional information required for the operation to complete (or to be cancelled).
Your architecture is wrong. Why:
Service cannot callback client's browser. Real callback over HTTP works like reverse communication - client is hosting service called by the client. Client in your case is browser - how do you want to host service in the browser? How do you want to open port for incoming communication from the browser? Solutions using "callback like" functionality are based on pooling the service. You can use JavaScript timer and implement your own pooling mechanism.
Client browser cannot initiate distributed transaction so you cannot start transaction on the client. You cannot also use server side transaction over multiple operations because it requires per-session instancing which in turn requires sessinoful channel.
WCF JSON/REST services don't support HTTP callback (duplex communication).
WCF JSON/REST services don't build pooling solution for you - you must do it yourselves
WCF JSON/REST services don't support distributed transactions
WCF JSON/REST services don't support sessionful channels / server side sessions
That was technical aspect of your solution.
Your solution looks more like scenario for the Workflow service where you start the workflow and it runs till some point where it waits for the user input. Until the input is provided the workflow can be persisted to the database so generally user can provide the input several days later. When the input is provided the service can continue. Starting the service and providing each needed input is modelled as separate operation called from the client. This is not usual scenario for something called from JavaScript but it should be possible because you can write custom WebHttpContextBinding to support workflows. It will still not achieve the situation where user will be automatically asked for something - that is your responsibility to find when the popup should appear and handle it.
If you leave standard WCF world you can check solutions like COMET which provides AJAX push/callback.
I have a DAL that is replicated across multiple apps (I know its a bad design but ignore this for now) , what I want to do is this...
Create a WCF DAL Component that will be accessed via all Desktop apps.. Could anyone share their thoughts on following ??
I am intending to use TCP Binding
What will be the overhead in terms of performance ( since 1 DAL component will b consumed via multiple apps )???
Since TCP Binding can only be hosted on IIS-7.0, this will be another overhead in terms of hardware+s/w ( or is it possible to have HTTP binding at top and TCP beneath that so that I can use IIS version 5 or 6 )???
Can I have multiple end points for multiple apps and is good from performace point of view as it will help us creating different thread for different client apps and can have diff contracts in future as well so that one application goes unaffected due changes in the DAL..
What Instancing Mode is preferred in this case (we are expecting a traffic of 100 concurrent user per day) , and DAL already handles this using SINGLETON design pattern.
Let me know your thoughts on all of above mentioned points and also if you could provide me more insight on this... will b gr8.
Thanks in advance...
Let me answer a few:
1) netTcpBinding is a great binding - very fast, very good in performance - definitely go with that!
3) Either host in IIS 7.0, or then self-host - write a little Windows NT Service and handle the hosting yourself. Gives you more control, and the ability to manually start and stop your DAL Service. I wouldn't even bother trying to get NetTcp working on IIS5/6 with some kind of a trick/hack - waste of time.
4) Multiple endpoints of the same binding are neither useful, nor do they help with performance.
5) I would always use "Per-Call". Each service request gets its own instance of the service, the call is handled, and then you're done. That makes programming the WCF service implementation a snap - if you go singleton, to have any performance at all, you need to worry about multi-threaded and thread-safe programming - a mess, really. Don't do it. NO, just don't do it.
A DAL should always be stateless and should operate on the "open the database connection as late as possible, do the work, and close the connection as soon as possible" again pattern which is a perfect fit for the per-call instance mode. When your service request comes in, the connection is opened (those are pooled in a connection pool in ADO.NET anyway, on the server side), the works is done, and the connection is closed again.
I am developing a WPF application that talks to a server via WCF services over the internet. After profiling the application I noticed a lot of time is being taking up by creating the appropriate WCF client proxy and making the call to the server.
The code on the server is optimised and doesn't take any time to run yet I am still seeing a 1.5 second delay from when a service is invloked to it returning to the client.
A few points to give a bit of background:
I am using the ASP.Net membership for security
I will eventually hook into the same server side code through a website
I would eventually like to have offline support in the application
I really need to nail the performance early though as if the app is taking a couple of seconds to come back it is too long for what I am trying to do.
Can anyone suggest performance tips that will help me please?
The client side proxy in WCF is basically made up of two parts. If you control both ends of the communication - e.g. if you write both the server and the client side - you can optimize this by doing the following steps:
isolate all service and data contracts into their own separate assembly
reference that assembly on both the server side (to implement your service), as well as the client side
Doing so, you don't need to create a "generic" client-side proxy by using Add Service Reference, but instead, you can take that process apart into two separate steps:
first step is to create a ChannelFactory<T> using your service contract, e.g.
ChannelFactory<IMyService> factory = new ChannelFactory<IMyService>();
Because you need to have access to the service contract on the client side, you need to separate those contracts out into their own assembly, so that you can reference that same contract on the client side. Creating the channel factory is the expensive part - you want to hang on to that channel factory and put it into a shared, cached container of sorts (your main form or something).
the second step is to create the actual channel (the "proxy") from the channel factory:
IMyService proxy = factory.CreateChannel();
This operation is much less resource intensive and can be performed before every service call and shouldn't cause much wasted time.
So with a few basic steps, you should be able to siginificantly simplify and speed up your construction of service client proxies.