How to scale a remoting application?
-
Hi guys! I'm a bit at a loss regarding the scalability of a client-server-application, perhaps someone can give me some tips... In this application, I have a .NET Remoting server running as a windows service. This server is using an SQLServer database and a file storage to perform the services it offers. All clients communicate with this single service via remoting (usually with TCP binary formatters for performance reasons). The problem is that I have no idea how many clients can be handled by the service (how could I test what's happening when 100 clients call methods on the server in parallel? How about 1000 or more?) and, what's worse, what to do once the maximum capacity has been reached. Each client has to know exactly one URI with server machine and port to contact for remoting to work, so how can I distribute the requests to different servers?
Regards, mav -- Black holes are the places where God divided by 0...
-
Hi guys! I'm a bit at a loss regarding the scalability of a client-server-application, perhaps someone can give me some tips... In this application, I have a .NET Remoting server running as a windows service. This server is using an SQLServer database and a file storage to perform the services it offers. All clients communicate with this single service via remoting (usually with TCP binary formatters for performance reasons). The problem is that I have no idea how many clients can be handled by the service (how could I test what's happening when 100 clients call methods on the server in parallel? How about 1000 or more?) and, what's worse, what to do once the maximum capacity has been reached. Each client has to know exactly one URI with server machine and port to contact for remoting to work, so how can I distribute the requests to different servers?
Regards, mav -- Black holes are the places where God divided by 0...
mav.northwind wrote:
Each client has to know exactly one URI with server machine and port to contact for remoting to work, so how can I distribute the requests to different servers?
Could this point of contact act simply as a gateway and hand off the actual work requests to other servers?
-
mav.northwind wrote:
Each client has to know exactly one URI with server machine and port to contact for remoting to work, so how can I distribute the requests to different servers?
Could this point of contact act simply as a gateway and hand off the actual work requests to other servers?
Thanks for your suggestion! That's one of the changes I had in mind, but I'm not sure how to actually do this or which architectural implications this yields. How would you "hand off" a request to a different server when the initial request is a method call to a server object? And, the initial server would stay the bottleneck unless there's a way to hand off the request in a way so that the result doesn't have to pass through the initial server, wouldn't it? Another way I thought of was a kind of broker that's assigning a server to a client, but that would require some changes at the client side and I'd rather have a scalable server architecture the clients don't have to know about.
Regards, mav -- Black holes are the places where God divided by 0...
-
Thanks for your suggestion! That's one of the changes I had in mind, but I'm not sure how to actually do this or which architectural implications this yields. How would you "hand off" a request to a different server when the initial request is a method call to a server object? And, the initial server would stay the bottleneck unless there's a way to hand off the request in a way so that the result doesn't have to pass through the initial server, wouldn't it? Another way I thought of was a kind of broker that's assigning a server to a client, but that would require some changes at the client side and I'd rather have a scalable server architecture the clients don't have to know about.
Regards, mav -- Black holes are the places where God divided by 0...
mav.northwind wrote:
How would you "hand off" a request to a different server when the initial request is a method call to a server object?
Hmmm. Here's how I think it would work: when the client calls a method on the server object it's only aware of the data (if any) required by the method and the result (if any) returned by the method, but it doesn't know how the method is implemented. In this case, then as long as the contract between the client and the server is honoured, then you can change the implementation as much as you want. For example given a server method like
List<user> GetAllUsers()you could have this method contact a database directly and return a result, or it could asynchronously call a method on another server (the hand off) and when it gets the result back return that to the client.mav.northwind wrote:
And, the initial server would stay the bottleneck unless there's a way to hand off the request in a way so that the result doesn't have to pass through the initial server, wouldn't it?
In a way yes I guess it is, but in another way no I guess it isn't. I've been doing a fair bit of research/implementation on web services lately (not that this makes me an expert), and by far the biggest win for me is having this well defined single point of contact for clients to connect to*, which means I can make changes at the server and never need touch the clients. If at some point in the future I introduce a webmethod that taxes the current hardware, I can do what I described above and have the actual meat of that method execute on another machine. The clients won't be aware that this is what's happening, so I can make this switch pretty much seamlessly. There is another consideration in that I needed to guarantee that the web service box could handle all the requests and traffic. I set up a little test with a webmethod that simply returned about 10Kb of text to the client. Overall I found that the server could easily deal with huge numbers of this type of request per minute - it didn't even break a sweat! But should the need ever arise I can add more bandwidth, more ram, a faster cpu, more cpu's etc etc. Along with the failover backup and the ability to hand intensive tasks off to another server without the client being aware of this I *think* what I've got is a fairly scalable, robust and predominantly "up" architecture (although time will tell). From an