Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This section describes how to tune the Aggregation agent with file storage.

Aggregation Cache

The Aggregation agent can store sessions on the file system, using a storage server, but also in a cache. The maximum size of the cache will be determined by the  Max Cached Sessions  parameter in the Aggregation profile (see Aggregation Profile in 9.23.6.1 Performance Tuning with File Storage) and the average size in memory of a session. It is difficult to estimate the exact memory consumption through testing but the following should be considered when implementing an Aggregation workflow:
 

...

Tip
titleHint!

To speed up the start of workflows that run locally (on the EC), set the Execution Context property  mz.aggregation.storage.profile_session_cache  property in the relevant <pico>.conf file to true (default value is false).

By doing so, the aggregation cache will be kept in memory for up to 10 minutes after a workflow has stopped.

This in turn enables another workflow, that runs within a 10 minute interval after the first workflow has stopped, and that is configured with the same profile, to use the very same allocated cache.

Note that since the cache remains in memory for up to 10 minutes after a workflow stopped executing, other workflows using other profiles might create caches of their own during this time.

The memory space of the respective aggregation caches will add up in the heap. If the EC at a certain point runs out of memory, performance deteriorates as cache is cleared and, as a result, sessions have to be read from and written to disk.

The profile session cache functionality is only enabled in batch workflows where the Aggregation profile is not set to read-only, and the storage is placed locally to the EC.

Memory Handling in Real-Time

...


Warning
titleWarning!

In real-time, when memory caching without any file storage, i e Storage Commit Interval is set to zero, make sure that you carefully scale the cache size to avoid losing a session due to cache over-runs. An over-run cache is recorded by the system event in the System Log. For further information, see  9.2.8 Aggregation Session Inspector.

While the aggregation cache will never cause the EC to run out of memory, it is still recommended that you set the Max Cached Sessions low enough so that there is enough space for the full cache size in memory. This will increase system performance.

Multithreading

If you have many sessions ending up in timeout, you can improve the performance by enabling multithreading, i e use a thread pool, for the  timeout  function block in the Aggregation agent. When multithreading is enabled, the workflow can hand over sessions to the pool via the queue without having to wait for the read operations to complete, since the threads in the thread pool will take care of that. With many threads, the throughput of read operations completed per second can be maximized.

...

Info
titleExample - Enabling multithreading, setting the property value to 8


Code Block
languagetext
themeEclipse
mzsh topo set topo://container:<container>/pico:<pico name>/val:config.properties.mz.aggregation.timeout.threads 8



Scroll ignore
scroll-viewportfalse
scroll-pdftrue
scroll-officefalse
scroll-chmtrue
scroll-docbooktrue
scroll-eclipsehelptrue
scroll-epubtrue
scroll-htmlfalse


Next: