2

I want to make the "TRAP AGENT" library. The trap agent library keeps the tracks of the various parameter of the client system. If the parameter of the client system changes above threshold then trap agent library at client side notifies to the server about that parameter. For example, if CPU usage exceeds beyond threshold then it will notify the server that CPU usage is exceeded. I have to measure 50-100 parameters (like memory usage, network usage etc.) at client side. Now I have the basic idea about the design, but I am stuck with the entire library design.

I have thought of below solutions:

  1. I can create a thread for each parameter (i.e. each thread will monitor single parameter).
  2. I can create a process for each parameter (i.e. each process will monitor single parameter).
  3. I can classify the various parameters into the various groups, like data usage parameter will fall into network group, CPU memory usage parameter will fall into the system group, and then will create thread for each group.

Now 1st solution is looking good as compare to 2nd. If I am adopting 1st solution then it may fail when I want to upgrade my library for 100 to 1000 parameters. Because I have to create 1000 threads at that time, which is not good design (I think so; if I am wrong correct me.)

3rd solution is good, but response time will be high since many parameters will be monitored in single thread.

Is there any better approach?

space earth
  • 407
  • 4
  • 18
  • 1
    One thousand threads is probably better than one thousand processes, but not by much. I think option 3 sounds better. You should work out how much CPU time (etc) each parameter is going to need. If you're not careful you're going to be working the system so hard on the monitoring that it won't be able to get real work done. If you aren't overworking the system (and you shouldn't be), then option 3 sounds better, and better. Indeed, you should be able to think about using a minimal number of threads in a single process. – Jonathan Leffler Nov 05 '15 at 07:09
  • 1
    Jonathan Leffler :Thanks.. i can also minimize the thread by dividing parameter in two groups:emergency parameter,non emergency parameter.Emergency parameter needs to be notified to server urgently(like system temperature,cpu over clocking etc.)so ideally i have required 2 threads only.(considering there are very few emergency parameters) – space earth Nov 05 '15 at 08:43

2 Answers2

2

In general, it's a bad idea to spawn threads 1-to-1 for any logical mapping in your code. You can quickly exhaust the available threads of the system.

In .NET this is very elegantly handled using thread pools: Thread vs ThreadPool

Here is a C++ discussion, but the concept is the same: Thread pooling in C++11

Processes are also high overhead on Windows. Both designs sound like they would ironically be quite taxing on the very resources you are trying to monitor.

Threads (and processes) give you parallelism where you need it. For example, letting the GUI be responsive while some background task is running. But if you are just monitoring in the background and reporting to a server, why require so much parallelism?

You could just run each check, one after the other, in a tight event loop in one single thread. If you are worried about not sampling the values as often, I'd say that's actually a benefit. It does no help to consume 50% CPU to monitor your CPU. If you are spot-checking values once every few seconds that is probably fine resolution.

In fact high resolution is of no help if you are reporting to a server. You don't want to denial-of-service-attack your server by doing a HTTP call to it multiple times a second once some value triggers.

NOTE: this doesn't mean you can't have a pluggable architecture. You could create some base class that represents checking a resource and then create subclasses for each specific type. Your event loop could iterate over an array or list of objects, calling each one successively and aggregating the results. At the end of the loop you report back to the server if any are out of range.

You may want to add logic to stop checking (or at least stop reporting back to the server) for some "cool down period" once a trap hits. You don't want to tax your server or spam your logs.

Community
  • 1
  • 1
modal_dialog
  • 733
  • 5
  • 12
  • 1
    modal_dialog:yes,your approach "creating one thread" is good since i have to monitor all the parameter for specific time interval.But some parameter(rather i will call "emergency parameter")needs to be notified to server urgently(like system temperature,cpu over clocking etc.)at that time i have to define thread for each "emergency parameter". – space earth Nov 05 '15 at 08:37
  • 1
    You still don't need a separate thread assuming all checks (i.e. one pass through the loop) finishes quickly enough. If for example it takes 5 seconds to finish all checks, that means you'll report high temp within 5 seconds which seems reasonable. I would build it in one loop first (start simple), and only add threads if and when it's taking too long. If that case arises, perhaps have one low priority thread and one high priority thread. – modal_dialog Nov 05 '15 at 08:40
  • 1
    There's also nothing stopping your from immediately reporting back for emergencies instead of continuing the other checks. You still don't need another thread. I think you may be overestimating how practical (and even useful) it is to get instant responses. You should be able to check 1,000s of parameters at a time in a time scale of at most seconds. That should be a good resolution for anything a separate server can do in response. – modal_dialog Nov 05 '15 at 08:45
  • 1
    modal_dialog:yes,your answer has solved most of my problems.but i have to also port the same library on panda board,raspberry pi.will response time decrease at that time?beacuse these boards are quite slow as compare to desktop computer, – space earth Nov 05 '15 at 08:51
  • 1
    Well, it's a good question, will it be slower? My hunch is that testing params like CPU usage, temp, etc. will not be much slower. These things are comparatively slow on all systems. But good design principles say that you don't complicate your design for *anticipated* performance issues, i.e. "premature optimization" http://stackoverflow.com/questions/385506/when-is-optimisation-premature. Nevertheless, the best bet would be to try some simple prototype code on the platforms you are concerned about, before getting too far in the dev process. – modal_dialog Nov 05 '15 at 08:54
1

You can follow below methodology:

1.You can have two threads one thread is dedicated to measure emergency parameter and second thread monitors non emergency parameter. hence response time for emergency parameter will be less.

2.You can define 3 threads.First thread will monitor the high priority(emergency parameter).Second thread will monitor the intermediate priority parameter. and last thread will monitor lowest priority parameter. So overall response time will be improved as compared to first solution.

3.If response time is not concern then you can monitor all the parameters in single thread.But in this case response time becomes worst when you upgrade your library to monitor 100 to 1000 parameters.

So in 1st case there will be more response time for non emergency parameter.While in 3rd case there will be definitely very high response time. So solution 2 is better.

jkd
  • 90
  • 5