In the previous post How to measure your system performance, I’ve given common description of your own ERP system performance. Now I would like to concentrate on what performance metrics we can collect.
First of all let’s try to list metrics that are important from users’ point of view and that cannot be measured by basic SQL Server and Windows Server mechanisms:
- Time that is required to open lists/journals of documents and ref books.
- Time that is required to open documents for viewing and editing.
- Time that is required to save changed documents.
- Amount of database timeouts.
- Amount of internal system exceptions.
- Time of reports creation.
- System response time.
To collect listed above metrics the architecture of ERP system must fulfill some requirements:
- System must have thin client – all logic must be on server side.
- System must have basic methods for all operations with business documents – so all custom logic of specific documents must be inherited from these basic methods.
- System must have common procedure for processing of all exceptions.
Following these principles the basic architecture will look like:
Class structure can be presented like:
So, in this case we have just one place where we must implement collection of the performance metrics. Now let’s try to consolidate all performance counters we have listed above and determine where we’re going to collect them.
| Metric | Place |
| Time that is required to open lists/journals | In basic procedure that responsible for getting and returning to user data of the required list/journal. |
| Time that is required to open documents | In basic procedure that responsible for getting and returning to user data of the required document. |
| Time that is required to save documents | In basic procedure that responsible for checking and storing data of the document in the database. |
| Amount of exceptions | In the module that is responsible for exception processing. Before sending exception to the user must store it in the database. |
| Amount of database timeouts | The special case of the previous point. |
| Time of reports creation | The structure of reports module must be the same as open/save one. In this case the logic would be similar. |
| System response time | Can be measured by external (such as IP-monitor) or by self-created programs. It’s important to build a correct method that would be called by utility. |
To sum up, I have described common architecture principles that are desirable to keep in order to build scalable and easy to maintain system of performance metrics collection. Also I have listed basic metrics that cannot be caught by server tools but rather important to understand when something has gone wrong. And finally I have identified places where we can catch these metrics.
In the next post of the series I’m planning to speak about common Statistics database structure – how to store all collected data.