The practice of automating the measurement of performance indicators EDMS

    Electronic document management systems and ERP-systems are complex software products, most often consisting of many subsystems. Parts of any system work both directly in the dialogue with the user and in the background, performing a certain part of the tasks on the server.

    In order to monitor system performance in both directions, the system administrator needs convenient measurement tools that allow you to find the weak link in time and take steps to improve performance. In this article I will share my experience in how to solve the issue of automatic measurements of system performance indicators using the example of an electronic document management system *.
    Unlike other software products, there are certain performance requirements for an EDMS: this is one of the important parameters that you need to monitor.

    * This article will be especially useful for beginning administrators of Docsvision, but in general the experience described is applicable to similar products.


    In addition to functionality and design, a key parameter for any software is the speed of work, and this factor is especially significant in the case of a complex system such as electronic document management systems.

    Imagine that a clerk-user in the workflow needs to quickly perform a number of actions: open the navigator *, create new cards and view existing ones, attach documents / files to cards, search for a large number of documents, generate data for reports. And you need to do all this quickly.

    Let's go back to the basics: what determines the speed of the system?

    In general, the speed of each of the links in the application and the speed of interaction between the links. In complex software, there can be many links, then the speed will be proportional to the work of the slowest link.

    For example, the Docsvision electronic document management system is an application with a client-server architecture, and we use:
    1. IIS as a web server
    2. MS SQL Server as a DBMS
    3. Client application written in .NET and WCF

    * Navigator - this is what Docsvision calls the main workstation of an EDMS user.

    To simplify it completely: a user working in the Docsvision Navigator client application exchanges requests from a web server from his workplace, receiving / sending certain data (this allows you to work in Docsvision both on a local network and via the Internet (http / https to choose.)

    I’ll note right away that for applications that use IIS (Apache, NGINX) as a web server and MS SQL as a DBMS, the recommendations given in the article will also be relevant.

    If we return to the listed tasks of the clerk, all of them (and not only them) are executed at different speeds, and all of them can be measured if desired to determine the degree of system performance.

    As a rule, software manufacturers initially provide data on key performance indicators. For example, a list of key indicators (and their values ​​for the corresponding version of Docsvision 5) is officially published by DoxVision in the document “Docsvision 5 Installation and Administration Guide”.

    These indicators include:
    • Launch of the Navigator (“cold” start)
    • Open the document card of the UD (the first after the launch of the Navigator)
    • Open the card of the document of the UD (subsequent)
    • Open the card of the task of the UD (first after the start of the Navigator)
    • Opening of a card. Task of DD (subsequent).

    The values ​​of these indicators are obtained empirically at a load test site during stress testing for 500 simultaneously working users. You can read more about the methodology for performing stress testing of the EDMS in an article on the DoksVision website: And also in our previous post on Habré:

    Measurement methods

    How to check on your own the compliance of the implemented system with the manufacturer's stated indicators? Based on our own experience, as well as the experience of our partners, a number of tools and recommendations have been formed for the optimal implementation of this task.
    You can arm yourself with a stopwatch to measure, for example, the opening time of the client application (“Navigator”), but this is not a completely professional approach. We will use the utility familiar to every web developer:


    Since the client application accesses the web server, we will use the Fiddler utility ( )

    In this case, fiddler acts as a proxy server, through which all client requests go (here we are interested in requests from the Docsvision Navigator application).

    So it’s quite convenient to look at the speed of query execution, and, importantly, this information can be used as a diagnostic of performance problems. It can be said with great accuracy where there is a slowdown on the client (weak hardware, poor network channel, slow rendering of the interface) or on the server.

    Fiddler allows you to find out the following:
    1. The number of server calls.
    2. Duration of server calls.
    3. The nature of the server logic being called.
    4. Distribution of server calls in time.
    5. Distribution of the script running time between the client and the server (it is very useful to find out exactly where the performance slipped).

    JetBrains dotTrace Performance

    Our colleagues (in terms of software development) from JetBrains are developing quite a lot of useful tools for developers. One of the applications can be used to analyze system performance indicators.
    DotTrace is a proprietary profiler for tracking performance problems and memory bottlenecks in applications on the .NET platform.

    This tool is quite powerful and allows you to:
    1. Use several profiling modes (including changing the execution time of a subprogram flow).
    2. Compare images ("traces") taken from different systems (in some cases it is useful to compare images of two client workstations).
    3. Keep statistics on the functions used and the time of their execution (to find out exactly what worked suboptimally - search for a folder or preview a file).
    4. Profile the memory occupied in the system.

    In the context of Docsvision: while searching for performance problems, we recommend profiling and analyzing (with our help) both client and server components of the platform. This tool is used mainly by developers to diagnose problematic scenarios at work.

    Navigator Log

    If you don’t have anything at hand, you can analyze the application using your own tools. The application has the ability to enable its own diagnostic log.
    Most often, the diagnostic log of the navigator is used to localize errors in the work, but in addition it contains information about all the operations performed by the Docsvision Navigator application. Those. only client operations of a specific application for which a log is logged are logged.
    The log looks something like this:

    In the log, you should pay attention to:
    • Opening the navigator
    • Regular closing of the navigator (paired with the operation “Opening the navigator” gives indirect information about the events of abnormal termination of the Navigator)
    • Duration of opening the navigator
    • Duration of opening the card
    • Duration of opening the node folders
    • Duration of building the presentation in the folder

    Since reading the log using text editors is not always convenient, Docsvision administrators can use the Docsvision Navigator Log Parser utility. This is our own development, which can be requested from technical support staff.

    It is pleasant in that:
    • simplifies the analysis process of the extended navigator log, isolating only information about useful operations;
    • knows how to separate the first (the first after the Navigator started operation) and the subsequent opening of documents and tasks cards;
    • knows how to select operations in a given time / date range;
    • the result of processing the extended log of the navigator is displayed in a separate csv file for further more detailed analysis.

    Server side

    In the course of researching the client application for performance, it may happen that, after analyzing the data of the client applications and detecting the absence of problems, it is necessary to audit the server part (DBMS). In this case, it will be necessary to profile the server side, focusing on typical MS SQL administrator tools.

    SQL SERVER profiler

    The standard utility for SQL server administrators allows you to see absolutely all queries to all databases in your possession.
    Using certain profiling templates, you can get a lot of useful information:
    1. Find out what operations in the database and how long they are performed
    2. Find out about the presence of dead locks (Deadlocks)
    3. Find out the execution plan of queries and stored procedures

    Of course, these methods are applicable not only to the Docsvision database, but also to any SQL database. The data collected in this way helps not only to see the speed of certain operations, but also to prompt the Docsvision Administrator (along with DBA) on steps to optimize performance. In fact, this topic is quite extensive, and is suitable for a separate article. MSSQL administrators, armed with SQL Profiler and Database Tuning Advisor, can put their knowledge into practice by optimizing the database.

    Objectivity and representativeness of measurements.

    In order to obtain accurate results during measurements, I recommend taking into account the following factors.
    • Representativeness. It is enough to analyze the performance of a user group without the need to analyze performance at all workplaces.
    • Objectivity. Measured indicators should be expressed quantitatively and calculated without the influence of subjective factors in an automatic mode. This, for example, a failure of the hardware part or a problem in third-party software that interferes with work (anti-virus software, firewalls, network point-to-point routers).
    • A selection of users.

    When conducting measurements in the EDMS, it is enough to select active users (up to 10 is advisable) that satisfy the following (at least one) criteria: the
    EDMS is the user's main working tool;
    • Users create documents and tasks;
    • Users process documents (for example, register) and tasks (for example, complete);
    • Users reveal various folder nodes;
    • Users open standard and virtual folders.

    At the same time: the group covers various scenarios of users in the system; equipment of user workstations meets the recommended requirements of the software developer; users present different working conditions with the EDMS in terms of connection methods (local from different network segments, terminal).


    It is equally important when taking measurements:
    • pay attention to monitoring the conditions under which performance indicators are obtained (measuring the load of the EDS equipment): client computers of the group, network connection to the application server, server.
    • analyze data on the loading of equipment upon receipt of unsatisfactory performance indicators.
    • perform database profiling when identifying slow data operations on servers.


    For measuring performance, not only the developed tools (logging built into the platform) are used, but also a wide range of familiar applications that will help diagnose jobs in a short time.

    In certain situations, it is possible to use only built-in tools: for example, it can be useful when working "in the field" on the customer side, when there is no access to a wide range of tools and applications.
    Third-party diagnostic tools should be used thoughtfully and commensurate with the tasks set.

    Surrounded by numbers and graphs, you need not to break away from reality. It is advisable to keep the application working, so that the effect of optimization after measurements can be felt in combat conditions.

    Also popular now: