Adjustments - Questions and Answers

After you have got a rough estimation of what to expect, there are some additional aspects to be taken into consideration, which may affect the sizing. Below you find a list of possible questions and answers concerning system sizing adjustments.

This page includes the following:

General Issues

Is the expected load distributed over the day evenly or do you expect high peaks?

Normal: -
Even: Reduce resources
High Peaks: Add resources (cores, WPs)

Is excellent performance important even in periods of peak load?

No: -
Yes: Add resources (cores, WPs)

Is the expected load constant or do you expect growth?

Constant: -
Growth: Consider next sizing level

How long do you need to hold data (statistics, job reports, revision reports) in the database?

> 12 month: Add more database storage
< 3 month: Reduce database storage

Do you expect many huge job reports to be stored in the database (e.g. more then 100.000 lines)?

No: -
Yes: Add more database storage

Do you plan to use ILM?

Yes: Plan how to deal with switched out data
No: Run the AE DB Reorg utility as near as possible to the database and add storage for output data (if generated)

Do you plan to use Oracle as database system?

Yes: Add resources on the database node(s) (faster CPUs, faster network, etc. )

What hardware to you plan to use for the AE system?

Linux/Windows on Intel x64: -
Others: Add resources

Do you plan to run the AE/database on virtual nodes?

Yes: Make sure that computing power is guaranteed for your systems and other Virtual Machines do not detract from the computing power/bandwidth.

Is logging and traceability over a longer period important for you?

Y: -
N: Reduce local disk storage on AE

Fail Safe

Is a fail safe system important for you?

No: -
Yes: Make sure your systems are equipped with redundant components (power supply, network, and so on) and that you have an "always-on" database environment.

Performance during a failure situation (e.g. one node fails): Are the remaining node(s) able to handle the load?

For example, a two-node system has to be oversized by 100% to be able to handle the load on the remaining node. Consider not only cores and memory, but also the amount of CPs, WPs, DWPs, JWPs, DB-Service agents, etc.

If fail safe is crucial for you, consider to run on more than two nodes.

Agents

Do you expect high usage of some agents?

No: -
Yes: Add resources to those nodes. Take care that resources used by your jobs are available.

Do you plan to run many agents on a single node such as SAP or WebService?

No: -
Yes: Add approximately 1 GB per Java-based agent to those nodes

An average used java agent will need between 512-1024 MB, but in some cases this may be more.

Users

Do you have many users, who are constantly monitoring activities and workflows?

No: -
Yes: Add more resources to dialog processes (DWPs) and AWI

Run more DWPs and take care that cores and memory are available for this additional load.

Do you expect huge workflows (> 1000 tasks per workflow)?

No: -
Yes: Add memory to AE / AWI

Expect 1-2 GB per DWP.

Do you expect huge xml imports/exports?

No: -
Yes: Add memory to AE / AWI

Expect 1-2 GB per DWP.

Automic Web Interface

Do you expect to have users in different locations (long distance)?

No: -
Yes: Run multiple AWI instances at every location (for example, on every continent where users are located)

Do you expect a high load at a particular location?

No: -
Yes: Run one strong server with plenty of RAM (see high end configuration)

Does load balancing make sense?

In general, the AWI needs little CPU, just plenty of RAM. Load balancing for performance does not make sense. Most load balancers do not support websockets, which the AWI uses and which reduce our resource usage per session and improves UI responsiveness. If you want to use a load balancer for high availability, see Configuring the Automic Web Interface.

Are you experiencing slow response times?

If the CPU on the servlet container running AWI is low and you are sure that your database can handle the increased I/O, try increasing the amount of DWPs and JWPs.

Does job processing slow down via database I/O by heavy web interface usage?

In times of heavy web interface usage, you can temporarily reduce the number of DWPs in order to take load off the backend while working on improving database I/O.

Analytics

What is the required disk space?

To estimate the disk space required in the datastore you can calculate with about 1GB for 1.000.000 executions in the Automation Engine.

Do I need to back up the datastore?

The Analytics datastore was created to store large amounts of data. If you have a medium or bigger installation it might still be useful to remove data older than approx. 1 year from the Analytics datastore. It is recommended to setup the provided backup actions (ANALYTICS ACTION PACK).

Which are the general database rules?

This is valid for all DB vendors - the log files must/should be placed on the fastest available disks (=SSDs).

ORACLE: REDO LOG FILE DESTINATION
SQL SERVER: TRANSACTION LOG and TEMPDB files
DB2: LOG files
LOG and DATA files must always be on separate DISKS /LUNS

Troubleshooting

Local system is too slow

CPU is too slow.
- Increase CPU speed
- Increase CPU count
Other apps consume too much CPU power on your node.

Run the Automation Engine exclusively on your nodes.
The system is under memory pressure.
- Add memory
- Reduce memory consumption
The virus scanner slows down I/Os.

Avoid running the virus scanner on your production node.

Database is too slow

Connection to the database is too slow.
- Increase network speed/capacity
- Reduce the distance to the database
Database transactions are too slow.
- Mirror or similar issues: Reduce the distance to mirror or use other (faster) fail safe features.
- Check CPU speed/usage/count
- Check memory size/usage
- Check storage speed/capacity/usage of other apps
- Check database maintenance (index reorganization, etc.)
- Check query optimizer (settings, statistics, etc.)
- Consult your database vendor for improvements