Infrastructure Monitoring

Hi,

I wanted ideas on how to achieve this efficiently using C++ concept:-

I have a DB table that contains rows of endpoints (say IDs vs names). There is process say "A" that calls another process B's API to increment counters if an operation is performed by an endpoint.
DB table:-
Once this increment happens, (say that endpoint[a2] with ID=2 is using process A to execute an increment counter) the endpoint entry is made in B's shared memory.
So at this point here's the state of DB and shared memory maintained by B:-
DB table:-
B's shared mem:-
/*format*/
/*ID,endpoint_name,counter_value*/
2,a2,1

Now there is another third-party application that reads and displays the no. of endpoints (using SNMP 'get') that have involved in the increment operation, which it'd get from the B's shared mem directly.
For this it does the follwing:-
1) Get the row count (say x)
2) In a loop it keeps fetching data 'x times'
So the display in third-party application would be (ID is NOT displayed):-
Now if row with ID=2 (a2) in DB table is deleted and created again it is represented in DB as ID=4 (B's shared mem would be unaware of these events). So at this point here's the state of DB table:-
B's shared mem:-
/*format*/
/*ID,endpoint_name,counter_value*/
2,a2,1

Now say that endpoint[a2] with ID=4 is using process A to executes an increment counter the endpoint entry is again made in B's shared memory.
Now B's shared mem:-
/*format*/
/*ID,endpoint_name,counter_value*/
2,a2,1
4,a2,1

Also in third-party app:-
This creates multiple entries with same endpoint name!!

[Note:- Fetching is done with ID as index but in display it is not included]
For process B to update its shared mem from DB when an increment is executed will hit performance as DB dip is a costly operation.

Any suggestions buddies?

What do you mean by "shared memory"? The memory's not shared if changes in A aren't automatically reflected in B's memory. If you make a proper shared segment, A's shared mem will always be the same as B's shared mem. They'd literally be referencing the same memory.

Instead of deleting counters could you just reset them to zero? Or, better yet, make the thing that deletes counters delete them from the shared memory. All DB modifications must update the shared mem to keep it consistent, otherwise it's untrustworthy hence not worth having.

OK let me put it this way; Process A updates the memory maintained by B using APIs exposed by B in say B.so lib. The DB operations are independent of shared mem.
Giving little more details on the project:-
Our's is VoIP switch that is used to make calls. So whenever an endpoint is involved in a call the call counter (maintained in B's mem) is incremented. So this means that even if there are 100s of endpoints provisioned in DB there may be no calls made. So the B's mem will always contain the active endpoints that've actually involved in the call. The counters that I mentioned were Resource usage counters.

@Corona688
Any help'd be greatly appreciated!

I see.

Whenever you modify the DB, you must update the shared mem. If you can't, there's no point in having it -- its contents can't be trusted. If the database isn't fast enough to rely on, you need a faster backend, or an improved interface to it -- try prepared queries, procedures, views. Try keeping a persistent connection somewhere instead of making a new one all the time.