Performance tips¶
Below are some tips for improving performance in various areas when using ecu.test. Since these may also have adverse side effects, they should only be applied on a case-by-case basis if an improvement could result from the given execution context.
ecu.test Runner¶
Especially for the use case where only a single test case (package or project) is to be executed, ecu.test_runner.exe can be used under Windows. See Executing a package or project for details.
In certain use cases, this can also replace remote control via REST API. In particular, delays and complexity due to status polling are minimized.
If ecu.test is remotely controlled via the test.guide ResourceAdapter, it is sufficient to replace the .exe name in the ResourceAdapter configuration.
Under Linux, the ecu.test Runner is used by default when calling ecu.test.
Version control¶
When Version control is activated, the revision is determined for each package called
during test execution and written to the report. While this improves traceability, it leads to
delays during execution. E.g., when using Git, determining the revision requires starting
git.exe for each file.
If traceability is ensured at another level or is not absolutely necessary, version control should be deactivated.
Caching and cache synchronization¶
For many types of test databases (e.g., A2L, bus databases, some models), ecu.test already creates local caches when the tool connection is started for the first time. These are reused if the database or model file has not changed since the last start.
If the initial loading of the database takes a considerable amount of time and the same test object is to be used on multiple test computers, local caching can be replaced by a cache exchange directory or a test.guide repository.
Log output¶
If a significant number of entries are created in the log during test execution, this can slow down the execution. In the log settings, the level Maximum should therefore only be selected if necessary for tracking errors.
Under normal circumstances, the options under Content should be deactivated.
To avoid making troubleshooting unnecessarily difficult, the levels Minimal or Off should only be used in exceptional cases where this is absolutely necessary for improving performance.
The option Write output log files synchronously should be disabled if possible to avoid blocking writes to the log file.
Garbage collection¶
Under certain circumstances, it may be useful to disable the Python garbage collector to avoid delays in processing test steps.
Size of the workspace¶
When loading a workspace, package information is indexed for high-performance access, e.g., for
workspace searches. With a very large number of packages (several thousand files), there may be
delays until all functions are available. We recommend limiting the size of a workspace for a
project and parts that are to be reused for multiple projects to Library workspaces.
The processing of very large prjattr.spec and pkgattr.spec files in the
.workspace directory also delays the start of ecu.test. These
should therefore only be as large as necessary.
License verification¶
At various times when using ecu.test, it is checked whether a valid license is available. If a server license is used, this can lead to delays depending on network utilization.
To avoid server interaction, a locally checked-out roaming license can be used, depending on the licensing model.
If a roaming licence is used, care should be taken to ensure that the licence is not
automatically renewed. This can be achieved by setting the environment variable
TRACET_RLM_ROAM to the value 0.
Virtualized Environments¶
The test execution performance also depends significantly on whether it is performed entirely locally on a physical machine or in a virtualization environment. The often limited resources there are sometimes subject to fluctuations, depending on the overall utilization of the virtualization environment.
The use of network drives for test artifacts or storing reports should be minimized if possible, as these can lead to significant latencies.