How to Create a Highly Scalable Windows Service?

Question

I have a Windows Service application which is installed on a Server. On one hand, it communicates with a local database and on the other hand it serves messages received from client applications.

The messaging between the server and client applications is via Sockets and I benefit its bidirectional and stateful messaging feature.

The client applications are windows services which are installed on the client machines (1 windows service per client PC).

We may have over 1,000 client applications each which sends almost 10 messages per minute to the Server Windows service, so you can imagine ultimately in the worst scenario the windows service has to serve about 10,000 messages per minute.

My question is what are the solutions to enhance the scalability of a windows service application?

Answer 1

This may give you some Idea about it:
http://www.codeproject.com/KB/recipes/ScalableWindowsService.aspx
Thanks and Regards,

---

Varun Kumar

Answer 2

Scalability is a very complicated goal, and it is something that has to be planned for early in the stages of development.  The general things to look out for are shared and limited resources.  Try to identify areas of contention for these resources and limit the amount of contention as best you can.  It can be very difficult to isolate concurrency bugs because it is difficult to reproduce them consistently, so a lot of thought must be given to the access patterns to these shared resources.

For example, one of the reasons that HTTP is a stateless protocol is to allow for scalability.  The client connects and sends a request, the server processes that request, sends a response and terminates the connection.  The server has now freed a limited resource to serve the next client.  Holding on to shared resources for the shortest duration possible is one of the most important things you can do to scale your application well.  You have to consider the advantages of having a stateful service against the resource consumption it tends towards.  It comes down to which is more expensive for your situation, sockets or managing the "state" of a stateless architecture?

You also have to consider whether or not you will be deploying multiple instances of the service.  If you are, and they point at a single database instance, the database may develop into a performance bottleneck as its load increases with each new deployment.

I hope that helps a little bit.  The take-home here is that scalability is a difficult problem and there are a large number of considerations.  It is largely a measure of performance, and the only way to test performance is to set goals, run tests, and gather metrics.  If you met your goals, stop, otherwise, make the necessary changes and try again.  Good luck!

Answer 3

Hi. Probably this is point where you may think in different terms than in terms of Windows programming. I mean more servers, and some new solution capable to work in such moved conditions. Standart services may be good for standart loads.

Best regards, Matt

Answer 4

Thank you guys for your comments and thoughts.

From my investigation, I have 2 potential solution:

1. Moving all the logic of my Server Windows Service into a WCF service which is hosted on IIS on Server, then I may be able to benefit IIS-enabled features such as load balancing. The communication between the WCF and the Windows Service again has to be bidirectional and stateful. So I thought maybe wsDualBinding may help.

2. Another option I was thinking was to dedicate a server as an entry point for the incoming messages from clients, then to distribute the load based on some logic to other servers. Server Clustering. I don't know yet how I can separate my load though because all the loads are very related to each other.