General configuration for all backends

This chapter contains the common settings for the databases PostgreSQL® and MS SQL®.

This list of values are key/value pairs for the configuration of these settings. The names (keys) are predefined by the backend in backend profile - see configuration of the backend profile. The further chapters are database-specific for the three different databases InfluxDB®, PostgreSQL® and MS SQL®.

Figure 1. Database-specific Configuration - Example PostgreSQL®

Logger for PostgreSQL® and MS SQL®

  • logger.level - the level of the log messages that produce the backend. Possible values are "trace", "debug", and "info", "warn" and "error".

    The default value is "info".

  • logger.logProtobufMessages – Set this flag to 1 for logging protobuf messages from/to frontend.

    The default value is 0.

  • logger.logToStdOut - Set this flag to 1 for logging parameters of the DB queries.

    The default value is 0.

  • logger.logSql - Set this flag to 1 for logging SQL messages to DB. The default value is 0.
  • logger.logSqlBindedParameters - Set this flag to 1 for logging parameters of the DB queries. The default value is 0

Backend configuration for PostgreSQL® and MS SQL®

  • backend.readThreadsNumber - size of thread pool for reading threads.

    The default is the number of CPU cores running on the computer. The backend splits read requests according to archive groups of requested elements.

    Each read request for a given archive group is executed in a separate thread. The size of the thread pool defines maximum threads that might be used simultaneously for handling read requests.

    If a value smaller than one is specified, the default value is used.

    For new PostgreSQL® databases created via a new project, the entry max_parallel_workers in the file postgresql.conf is set to the number of cores running on the computer.

    Once this has been done, the number of read threads in the PostgreSQL® backend (backend.readThreadsNumber) is adjusted to this number. This is only done for the standard backend _NGA_B_PostgreSQLBackend and is neither adjusted for other backends nor for existing projects.

    With these settings, the performance is improved for many parallel queries, for example in projects with many datapoint functions.

  • backend.writeThreadsNumber - size of thread pool for writing threads. The default value is 50. If a value smaller than one is specified, the default value is used.
  • db.timeoutToConnect - Specifies the timeout period, in seconds, for connecting to the database. The default value is 5 seconds. If the connection process takes longer than this time, the database is considered unavailable and the connection attempt will be stopped.
  • db.timeoutForQuery - Specifies how many seconds to wait for a response from the database before aborting the query with a timeout error. The default value is 0, which means there is no time limit (infinite wait).
  • backend.updateElementsForQueriesOnPassive - The default value is true. When the passive server executes queries, each query reads the ELEMENTS table again.

    For large projects (with over 100,000 archive DPEs), this process can be time-consuming, which reduces query throughput and increases the load on the passive server.

    If this setting is set to false, the update is skipped, improving performance. However, you should only set this to false at runtime when no new DPEs will be created or updated.

    Otherwise, queries for new DPEs will not work until you set this entry back to true. In such cases, after running a single query for the new DPEs, you can set the entry to false again. This setting has no effect on DirectRead.

  • backend.allQuerysCanSkipCacheUpdate - The default value is false. When set to false, DirectRead and the passive server reread the ELEMENTS table for every query.

    If this entry is set to true, the cache is refreshed only every 30 seconds, which improves performance.

    However, this means that during those 30 seconds, the system uses the old cache, and any newly created DPEs cannot be queried until the cache is updated.

    When the value is false (the default), only importer reads use this caching, since DPEs do not change during importing.

    When the value is true, every query uses this caching. In this case, you must be careful not to modify DPEs during the 30-second interval, as this could lead to unexpected results.