Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Stardust/Knowledge Base/Infrastructure System Administration Maintenance/Hardware And Sizing

User Environments

Any average developer desktop computer or laptop can be used to develop process models, test runtime environments and administer those. Typical hardware/software configuration might be the following:

Analyst

  • Regular dual- or quad-core core CPU
  • 2 GB RAM
  • Windows or LINUX derivates
  • 1 GB Hard disk for Infinity Process Platform
  • >14” monitor
  • SUN JRE 6

Developer

  • Regular dual- or quad-core CPU
  • 4 GB RAM
  • Windows or LINUX derivates
  • 3 GB Hard disk for Infinity Process Platform
  • >14” monitor
  • Connectivity to Maven Repositories (Internet or Local mirrors), IOD environment / Internet and code repository
  • SUN JDK 6

End user

  • Internet Explorer 9 or Firefox 26, 27 or Chrome 32,33 (others work but ar not fully tested)
  • Satisfying browser’s requirements
  • Internet / IOD Access


Server Environments

Please find the list of supported platforms in the release notes section of the online documentation or in the FAQ.

Integration Environment

  • 1 dual- or quad-core CPU
  • 4 GB RAM
  • 20 GB Hard Disk (depends on extent of integration tests)
  • a supported JDK
  • a supported applications server
  • a supported database server

The integration environment should preferable have the same software configuration as the production environment.

Production Environment

The required server hardware is influence by several factors:

  • number of concurrent users
  • number of concurrent root process instances per minute
  • complexity of processes (process hierarchy depth / number of activities per process hierarchy)
  • number of interactive activities vs. number of non-interactive activities
  • System load create by services running on the same server which are invoked as part of the processes

Whereas mainly STP-driven solutions create load on the application server(s), solutions with more user interaction create higher load on the database.

The process engine itself usually does not cause significant CPU load, but custom services which are executed as part of the processes may. Large, complex process models lead to higher memory requirements on the application server.

Information on the runtime state of processes and audit records are stored in the database. The required table space depends on the number of process instances, the complexity of the process definitions, the amount of process data stored in the audit trail db and the periodicity in which audit information is archived or deleted. For instance an audit trail holding 1 Mio. Processes / 10 Mio. activities and storing a bigger number of business data as process data could consume 70 GB of table space, using half of this for the process data. The section Technical Requirements to the Database Schema in the Stardust online documentation shows how the required table space can be estimated.

If the DMS component is used, storage of documents also needs to be considered. Documents can be either stored in a database or in the file system. The requirements depend on the number and size of the documents to be stored. In case of a clustered environment, the storage has to be transactional and support concurrent access from multiple processes.

Depending on high availability requirements for the solution, load balancing mechanism can be applied on portal level (e.g. F5 Load Balancer) as well as on process engine and DMS level (e.g. cluster and load balancing capabilities of used messaging system/provider).

A production environment is frequently hosted on

  • 1-2 application server nodes (depending on high availability requirements for the solution)
  • 1-2 database server nodes (depending on high availability requirements for the solution)
  • with 2-8 CPUs/cores per node
  • and 2-8 GB RAM per node


Example Customer Environments

Project
Characteristics
Process Instance (per day)
Named Users
Concurrent Users
Complexity
Application Server
Database Server
Operating System
Banking, Order Processing
Long running business processes including system integration and user interaction.
2500
300
50
high
2 Tomcat Server
(1.5 GB Memory / 2 CPUs)
1 Oracle 10g Server (4 CPUs)
Windows
Banking, Credit Approval Processing
Long running business processes including system integration and user interaction.
10000
6000
300
high
4 WebSphere Server (2 GB Memory / 4 CPUs)
1 DB2 Server (4 CPUs)
Solaris
Banking, General Resubmission Control
Short running business processes (process
creation and completion at the same day); intensive user interaction (high number of concurrent user access); no system integration.
60000
6000
1500
low
2 WebSphere Server (2 GB Memory / 4 CPUs)
2 Oracle 10g Sever (4 CPUs)
Solaris
Energy, Trading Hub
Long running business processes including system integration and user interaction.
3000
300
150
mid
1 Jboss Server
(2GB Memory / 2 CPUs)
1 Oracle 10g Server (2 CPUs)
Windows
Financial Message Processing, Straight Through Processing
Benchmark: High-volume message processing (peak 40000 msg/sec with < 500 ms latency from entry-to-exit); no user interaction; pure Straight Through Processing; based on Stardust's capability to flush Audit Trail transaction asynchronously (write behind Audit Trail logging)
144000000
1
1
mid
1 WebLogic
(2GB / 4 CPUs)
1 Oracle 10g Server (4 CPUs)
Solaris
Document processing, High speed scan and ICR batch Processing
Benchmark: High-volume document processing, user interaction (automated for performance tests); considers document creation, retrieval and process completion (see related article).

144000
1
8-12
low
 1 Jboss Server
(4GB Memory / 1 CPU /
4 Core)
1 Oracle 11g Server
(1 CPU / 4 Core)
Windows (64 bit)


Back to the top