For optimal performance, the number of wrappers (Session EJBs, Servlets, and such (Oracle WebLogic application server refers to wrappers as Bean Pools)) deployed should never exceed the number of CPU cores on the server hardware, minus an allocation to support the OS and other applications resident on the server, including middleware. Typically, the number of these wrappers is controlled via a configuration file.
Note: The CcServer.ear and CcServer.war files are available from the Progress download site in the PROGRESS_CORTICON_5.6.1_SERVER.zip package. The unpackaged files are typically installed in the Corticon directory [CORTICON_HOME]\Server\Containers\{EAR/WAR}. Refer to the Progress Software web page Progress Corticon 5.6 - Supported Platforms Matrix to review the currently supported UNIX/Linux platforms and brands of Application Servers. Also see the Corticon KnowledgeBase entry Corticon Server 5.X sample EAR/WAR installation for different Application Servers for detailed instructions on configuring Apache Tomcat, JBoss, WebSphere, WebLogic on all supported platforms.
The sample EJB code in Corticon's default installation sets the number of wrappers in the weblogic-ejb-jar.xml file (located in meta-inf of the EAR location's \lib\CcServerAdminEJB.jar and \lib\CcServerExecuteEJB.jar. Servlets are configured in a similar way. For example, a 4-core server box should have, at most, 4 wrappers deployed to it. Another example: a dedicated Corticon Server box with 16 cores should have at most 15 wrappers deployed, with 1 core of capacity reserved for OS and middleware platform.
Wrappers & pools
The number of wrappers should be greater than or equal to the number of available CPUs on the server. In version 5.5, the Corticon Server implemented its own Execution Queue to control how many threads can simultaneously execute inside the Corticon Server. By default, the Execution Queue will be configured to match the number of available CPUs on the machine, but this can be overridden by changing the following Corticon property in the brms.properties file, as follows:
############################################################################################ # This property will be used by the CcServer to determine how many concurrent executions can occur across # the CcServer. Ideally, this value will be set to the number Cores on the machine. By default, this value # is set to 0, which means the CcServer will auto-detect the number of Cores on the server. # # Default value is 0 (CcServer will auto-detect the number of Cores on machine and use that number) #############################################################################################
This value in the Decision Service is utilized when the CcServer is configured with Decision Service Allocation turned on. The following property needs to be set to true (default is false):
With the allocation property set to true, the CcServer can control how many incoming execution threads from each Decision Service will be added to the CcServer’s Execution Queue. If additional execution threads come into for a particular Decision Service, and that Decision Service has already allocated its maximum to the Execution Queue, then the incoming execution thread waits until an execution thread for that Decision Service leaves the Execution Queue.
Hyper-threading
Hyper-threading is an Intel-proprietary technology used to improve parallelization of computations (doing multiple tasks at once) performed on PC microprocessors. For each processor core that is physically present, the operating system addresses two virtual processors, and shares the workload between them when possible. Field experience suggests that Hyper-threading does not allow doubling of wrappers or Reactors for a given physical CPU core number. Doubling wrappers or Reactors with the expectation that Hyper-threading will double capacity will result in core under-utilization and poor performance. We recommend setting wrapper and Reactor parameters based on the assumption of one thread per CPU core.
