Specification
- C# Distributed Application.
- Client/Server design.
- Client (Winforms), Server (Windows Service), Communication via .Net Remoting.
- The below question relates to the Server-Side of the application.
- (EDIT) The Server-side of the application runs on a server with 8 Cores and 12Gb Ram
- (EDIT) The CPU of this server is always hitting around 80% Usage due to lots of other services being run on this same server.
Scenario
- I’ve inheritted a large legacy application.
- It carries out a bunch of tasks, some of them independently, but others not.
- The current design for this application involves the creation of 14 threads, each running either 1 task or a number of tasks.
- The problem is that I get the feeling this design element has an impact on performance.
Code Examples – How Each Class/Thread Is Designed & Run
public class ManageThreads
{
private Thread doStuffThread = null;
//Inside the constructor EVERY thread is instantiated and run.
//(I am aware that this example only shows the use of 1 thread).
public ManageThreads()
{
doStuffThread = new Thread(new ThreadStart(DoSomeStuff.Instance.Start));
doStuffThread.Start();
//Instantiate and run another thread.....
//Instantiate and run another thread.....
//Instantiate and run another thread.....etc.
}
}
public class DoSomeStuff
{
void Start()
{
while(true)
{
//Repeatedly do some tasks.....
Thread.Sleep(5000);
}
}
}
Thoughts
- What I’d like to do is keep the existing code, but modify the way that it runs.
- I’ve thought about the use of a Thread Pool to solve this problem, but given the current architecture I am unsure of how I would go about doing this.
Questions
- Would this current design affect performance in a noticeable way?
- Is it possible for me to improve the performance of this application without altering the underlying functions, but changing the design slightly?
- Can anyone recommend anything / advise me on the right way to go about improving this?
Help greatly appreciated.
Don’t guess, get a profiler out and measure what’s going on. Gather some empirical stats about where time is spent in the application and then you can take a view on where the pinch points are.
If the time spent creating threads is your biggest headache then moving to a threadpool may be the right answer, but you won’t know without some forensic analysis.
From the small snippet you’ve posted it looks like the 14 threads are reasonably long-lived, doing multiple things over their lifetime so I suspect that this is not the problem actually, but there isn’t enough info in your post to make a definitive call on this.