To ensure the best possible performance experience for system users, the following guidelines for the SystemWeaver mirror server usage are recommended. 


Sufficient Memory on Server Machine

SystemWeaver uses a so-called in-memory database. (http://en.wikipedia.org/wiki/In_memory_database) Basically, an in-memory database is a database management system that primarily relies on main memory for computer data storage. It is contrasted with database management systems that employ a disk storage mechanism. In-memory databases are faster than disk-optimized databases because disk access is slower than memory access, the internal optimization algorithms are simpler and execute fewer CPU instructions. Accessing data in-memory eliminates seek time when querying the data, which provides faster and more predictable performance than disk. If there is not enough RAM, it will be partially swapped to disk which will rapidly deteriorate performance. Monitor memory usage (for example in the swServer log) and make sure enough RAM headroom exists to avoid hitting the RAM capacity during the planned operation period. Read about our server hardware requirements.


DLQ File Logging

During the initial implementation period, we strongly recommend turning on the DLQ logging, especially if the mirror server will be used together with our REST API server. How to Install and Configure a Mirror Server covers how to configure DLQ logging. In addition, standard server logging should also be activated. 


SystemWeaver API

All guidelines outlined in Important Guidelines for API and REST API Usage apply for the usage of the API against a mirror server. Most importantly:

  • Never allow more than one API program to create and/or modify data in the same structure at the same time.

  • Creating/modifying large amounts of data should be done outside of working hours or the amount of write operations per second needs to be restricted so as not to affect the performance for other connected users. Every write operation is communicated to all connected users to keep them in sync, potentially making their applications slow or unresponsive if the server produces large amounts of update messages. If large batch operations must be done during business hours, we highly recommend that you script delays so as to break up the data into smaller batch operations.

  • If the connection to the server has a high latency, the performance of the API application when creating/modifying large amounts of data will be impacted. Make sure that the latency is as low as possible to minimize the execution time for the program.
  • Stay logged in to the SystemWeaver server if your API program reads data from the same structure repetitively. There is no maximum login time and when the application is passive it has no impact on the system. The local cache will improve the performance of your application and reduce the performance impact for the SystemWeaver server. Logging out will clear this cache.


REST API

As noted in Installing the SystemWeaver REST API Server, unless the usage of the REST API is going to be limited, we recommend that it connect to a mirror server. 


 For large installations and/or for heavy use, the REST API should not be installed on the main server machine and should not be configured to connect to the main server. Instead, the REST API should be installed on a designated mirror server machine and connect to a SystemWeaver mirror server.


In addition, all performance guidelines outlined in Important Guidelines for API and REST API Usage apply for the usage of a REST API against a mirror server. Most importantly:

  • Never allow more than one program to create and/or modify data in the same structure at the same time.

  • Creating/modifying large amounts of data should be done outside of working hours or the amount of write operations per second needs to be restricted so as not to affect the performance for other connected users. Every write operation is communicated to all connected users to keep them in sync, potentially making their applications slow or unresponsive if the server produces large amounts of update messages. If large batch operations must be done during business hours, we highly recommend that you script delays so as to break up the data into smaller batch operations.

  • If the connection to the server has a high latency, the performance of the API application when creating/modifying large amounts of data will be impacted. Make sure that the latency is as low as possible to minimize the execution time for the program.