EcoSys Server Settings - EcoSys - Help - Hexagon PPM

EcoSys Performance Tuning

Language
English
Product
EcoSys
Search by Category
Help
EcoSys Version
8.7

Database Connection Pool

Each application server has its own way to configure the connection pool. Refer to the Install Guide for specific steps to configure the connection pool.

Recommended Minimum Database Connection Pool Size

Low User Load

(1-25 concurrent users)

Medium User Load(25-75

concurrent users)

High User Load

(75-200 concurrent users)

Enterprise

(> 200 concurrent users)

Minimum Connections

10

20

20

20

Maximum Connections

50

80

100-400

>300

You must size the database connection pool to be large enough so that there is not frequent contention for database connections with the application. After you configure the connection pool, you can use the Server Metrics screen and associated logging in EcoSys to identify the level of contention.

Use the following methods to monitor the use of the database connection pool usage and wait times:

  1. In EcoSys, navigate to System Info > Server Metrics. Look the DB Connections and DB Conn Fetch Time rows in the data table there.

  2. You can also review the SERVERMETRICS lines in the EcoSys application log file. Locate the attribute/values for dbc(#) (database connections) and dbcft(s) (database connection fetch time). You can see the log from the front end using System Admin > Display Log, then filter for SERVERMETRICS. For nominal values, refer to following table.

Database Connections (dbc(#))

Database Connection Fetch Time (dbcft(s))

This metric shows the average number of database connections in use over the sample interval.

If the metric frequently approaches the number of connections configured in the database connection pool, you may need to increase the pool size.

If the metric is usually substantially below the maximum, you may be able to reduce the pool size to conserve database resources.

This metrics shows the average amount of time per second over the sample interval that the system had to wait to lease a connection from the connection pool.

If the metric is frequently over 0.0, your users are experiencing waits due to not having enough available database connections.

If the metric is usually zero, your connection pool size is likely not a bottleneck for performance.

PULS Parallel Load Save

Settings and Defaults

Notes

report.parallelLoad.maxThreadsPerRequest=10

For a more powerful server, set the number as high as 20.

report.parallelLoad.defaultThreadsPerRequest=2

For a more powerful server, set the number to 5. For each spreadsheet or report, the user can specify the number.

report.parallelSave.maxThreadsPerRequest=10

For EcoSys release prior to 6.0, set to 1.

report.parallelSave.defaultThreadsPerRequest=2

For a more powerful server, set the number to 5. For each spreadsheet or report, the user can specify the number.

report.parallelSave.minRowsPerThread=50

Specifies the tuning between performance and resource. The more resource and poorer performance, the higher number. Other recommendations 20 or 100.

PULS User Thread Pool

The settings in the following table are available only in EcoSysVersion 6+.

Settings and Defaults

Notes

server.CoreESThreadPoolSize=5

Indicates the number of threads guaranteed to be allocated. Setting this value higher than 25% of maximum thread pool size consumes more memory.

server.MaxESThreadPoolSize=50

Increase this number if you see a long waiting time of user threads. However, a higher number means using more memory at particular times. Other recommendation is to set this to 100.

server.ESThreadPoolkeepAliveTime=20

We do not recommend changing this value.

Scalability considerations are listed in the following table:

"Core"/"Max" Thread
Pool Minimum Size Recommendations

Low User Load
(1-25
concurrent users)

Medium User Load (25-75 concurrent users)

High User Load
(75-200
concurrent users)

Enterprise
(> 200 concurrent users)

32-bit System, 2 CPU Cores, up to 1.4 GB Java Heap

5/20

5/40

Not recommended

Not recommended

64-bit System, 4-8 CPU Cores, up to 5.0 GB Java Heap

5/20

10/40

20/100

30 / > 200

64-bit System, > 8 CPU Cores, > 5.0 GB Java Heap

10/40

20/100

30/200

**

** Custom benchmarking recommended for optimal configuration.

Use the methods below to monitor the PULS user thread pool usage and wait times.

  • In EcoSys, navigate to System Info > Server Metrics. In the data table, location the rows Thr. Pool Wait Secs and Wkg User Threads.

  • Use the EcoSys System Status Monitor dashboard (/ecosys/systemstatus) to display the number of working PULS user working threads.

  • Click System Admin > Display Log to open the EcoSys application log file, and then filter for SERVERMETRICS. Look for the attribute/values listed in the following table.

SERVERMTRICS Key Value

Units

Description

tpwait(s)

seconds

Thread pool wait time per second

tpwait(#)

count

Peak thread pool waiting jobs

tpthrc(#)

count

Peak thread pool thread count (size) over interval

tpwrkc(#)

count

Peak thread pool working count over interval

Nominal values are listed in the following table.

Working User Thread Count tpwrkc(#)

Thread Pool Wait Secondstpwait(s)

Shows the average number of PULS user threads in use over the sample interval.

  • If this metric frequently approaches the number of threads configured in the thread pool, you may need to increase the pool size.

  • If this metric is usually below the maximum, you may be able to reduce the pool size to conserve resources.

Shows the average amount of time per second over the sample interval that the system had to wait to lease a thread from the thread pool.

  • If this metric is frequently over 0.0, users are experiencing waits due to not having enough available threads.

  • If this metric is usually zero, your thread pool size is likely not a bottleneck for performance.

Reporting and Spreadsheet Row/Cell Limits

Settings and Defaults

Notes

reports.maxReportRecordCountWithCostsOrUnits=8000

Specifies the maximum number of rows loaded by a LANA definition with cost and/or unit fields.

reports.maxBatchJobLogRecordCount=150000

Specifies the maximum number of rows loaded by a Batch Job Log report.

reports.maxTaskRecordCount=50000

The maximum number of rows loaded by a Task subject area LANA definition.

reports.maxCostObjectRecordCount=50000

Specifies the maximum number of rows loaded by a Cost Object subject area LANA definition

reports.maxResourceRecordCount=20000

Specifies the maximum number of rows loaded by a Resource subject area LANA definition

reports.maxActualChargeItemRecordCount=100000

Specifies the maximum number of rows loaded by a Actual Transaction subject area LANA definition

reports.maxForecastChargeItemRecordCount=100000

Specifies the maximum number of rows loaded by a Forecast Transaction subject area LANA definition

reports.maxCategoryValueRecordCount=50000

Specifies the maximum number of rows loaded by a Category Value subject area LANA definition

reports.maxAuditAttributeRecordCount150000

Specifies the maximum number of rows loaded by a Audit Attribute subject area LANA definition

reports.maxAuditSpreadsheetRecordCount=150000

Specifies the maximum number of rows loaded by a Audit Spreadsheet subject area LANA definition

Database SQL Settings

Settings and Defaults

Notes

database.maxInClauseCount=700

Specifies the number of elements allowed in a single SQL where clause. The maximum for Oracle is 800.

database.fetchSize=100

Specifies the number of rows retrieved at once by a JDBC ResultSet. For larger row counts, you may increase this value to reduce number of trips across the network.

server.maxSessionFilterCount=5000

Specifies the maximum number of rows allowed to be enforced by session filters. This only applies to Versions and Organizations; Cost Object session filters may have unlimited number of rows enforced by a session filter.

Import and Commit Sizes

Settings and Defaults

Notes

database.maxInClauseCount=700

Specifies the number of elements allowed in a single SQL where clause. The maximum for Oracle is 800.

database.fetchSize=100

Specifies the number of rows retrieved at once by a JDBC ResultSet. For larger row counts, you may increase this value to reduce number of trips across the network.

server.maxSessionFilterCount=5000

Specifies maximum number of rows allowed to be enforced by session filters. This only applies to Versions and Organizations; Cost Object session filters may have unlimited number of rows enforced by a session filter.

Global Cache

The following table lists the settings for EcoSys Version 6+ only:

Settings and Defaults

Notes

server.dac.FundingRecipientScope=
CS_Global

For systems with more than 50,000 cost objects, use CS_Request.

server.dac.RateScope=CS_Global

none *

server.dac.udfScope=CS_Global

none *

server.dac.fundingdetailScope=CS_Global

none *

server.dac.fundingsourceScope=
CS_Global

none *

server.dac.globaltypeScope=CS_Global

none *

server.dac.budgetCatego ryScope= CS_Global

none *

server.dac.categoryType Scope= CS_Globa

none *

* The options for each cache are CS_Global or CS_Request. CS_Global is recommended for all caches.

Closeout Process

Settings and Defaults

Notes

server.closeout.usingSP=true

This setting must be absent or set to TRUE. The software does not support setting the value to FALSE.

server.closeout.nextKeyBlock=50

For large dataset, use large number. Example 3000

Query Cache

Setting and Default

Notes

database.querycache.enabled=true

We do not recommend disabling the query cache.

database.querycache.expirationSeconds=600

The value -1 indicates no expiration

database.querycache.invalidateSeconds=5

On a larger cache size, less frequent invalidation may conserve CPU resources. If stale cache hits are frequent (users seeing old data), a more frequent invalidation interval is recommended. Recommended to set to a value of 2-60

database.querycache.maxcachebytes=
10000000000

10% of Java heap size of the server

database.querycache.maxResultsetBytes=
1000000

10% of the database.querycache.maxcachebytes

database.querycache.checkResultSetSize=
true

If performance is critical, turn it off.

For scalability considerations, refer to EcoSys Support for assistance.

Report Instance Cache

The report instance cache (EcoSys version 6+ only) temporarily saves report output on the application server’s disk. This enables users to view the report output without re-running the report. The cache also speeds up export to Excel and PDF, as well as redrawing of chart reports quickly. We do not recommend that you disable the report instace cache.

Settings and Defaults

Notes

report.instanceCache.rootFolder=
c:/ESFM/report-cache

Set to local fast disk on the application server.

report.instanceCache.enabled=true

Not recommended to disable

report.instanceCache.exportAgeMinutes=60

If users experience long delays when exporting reports to Excel or PDF due to recomputing the data, increase this value from default. Recommended to set to a Minimum 5, maximum 180

report.instanceCache.autoExpireIntervalMinutes=60

Decrease from default if cache is using too much space on disk. Recommended to set to a Minimum 5, maximum 180

Cache hit ratios can be an indicator for how to adjust these values.

Application Tracing

Application tracing is controlled on the Application Tracing tab on the Application Settings screen. For normal production use, apply the Set to Defaults option so that unnecessary detail is not written to the application log, slowing down performance.

The recommended (default) values for application tracing are to disable all options except for: ERROR, WARN, ACTION, PROCESS METRICS, and SERVER METRICS.

The SERVER METRICS recommended intervals are listed in the following table.

SERVERMETRICS Usage Scenario

Update Log Interval*

SAMPLE Interval*

Recommended defaults for everyday production use.

120

10

If more detailed server metrics are needed, such as when benchmarking multi-user load scenarios, the intervals may be temporarily increased in granularity.

30

5

For very fine-grained measurements.

Some accuracy is diminished as the intervals are reduced.

10

3

Setting both intervals to zero and clearing the SERVERMETRICS option will disable SERVERMETRICS. This is not recommended unless troubleshooting.

0

0

* The SAMPLE Interval should always be less than half of the log update interval.

When troubleshooting performance, sometimes it is valuable to capture additional details. The most common approach is to temporarily enable these options: QUERY, QUERYPARAM, and METHOD.

These options should be set back to their defaults (disabled) immediately after the troubleshooting session is complete. Running with these options on will produce very large log files in a short amount of time.

Audit Level Settings

Settings and Defaults

Other Recommendations

Notes

server.enableAuditAttributeSystem=true

database.storeAuditAttributeXML=true

Set to true for finer detail audit records

Enabling this option can cause additional load and volume in the database. As such, we recommend that you enable it only if required by the business.

server.enableAuditSpreadsheetSystem=
true

Set to true for finer detail audit records

Enabling this option can cause additional load and volume in the database. As such, we recommend that you enable it only if required by the business.

server.enableAuditWorksheetSystem=true

Special Mode Settings

Setting and Default

Other Recommendations

Notes

mode.demo=false

mode.testing=false

mode.debug=false

None

These values must be set to FALSE or omitted from the file. None of these options should be enabled for production or end-user use, and their use is not supported.

server.internalLoggingAreas=

None

This value should be blank or missing. Other values for this settings are used only for internal troubleshooting or in special circumstances by EcoSys support staff.

server.has32BitLimitOnHeapSize=false

Set to "true" for 32-bit systems.

This value should be set to TRUE for any 32-bit JVM. This limits the heap size to 1.4 GB, preventing errors due to the JVM falsely reporting more addressable memory than it can use.