Some customers want to partition their XOG accesses away from their user base's web browser UI requests.
The reasons can be due to wanting to limit interference between the two, and to stop them contending for the same resources. It also means the load balancer app services can be scaled accordingly just based upon the needs of the UI users in a growing deployment.
To implement this, a customer would typically add another CA PPM 'app' service to their existing setup (it may or may not be on the same server as other app services - that is a question of available hardware resources).
So if we take an environment that has 4 app services today in production (load balanced), a decision may be made one of two ways to begin approaching this:
- Remove one of the app services from the load balancer pool, bringing them down to 3 services. Take the 4th service and reconfigure it to be dedicated for XOG.
- Add a 5th service to the environment, keep it out of the load balancer pool, and then tune down the configuration of the 4 app services if preferred once the XOG overheads are no longer needing to be considered there.
Which approach to take and how to scale up/down the configuration for the existing and new services would need to be individualized for each environment, it isn't possible to provide specific guidance in general.
Either way, once this is done, the XOG service will end up with a different URL for reaching it than the load balancer address used by most users. That URL value should be correctly entered into Entry URL fields for the XOG app service in the CSA, remembering that this is now a dedicated service for this purpose and will not be involved in the generation of notifications or export to excel activities or other actions where the load balancer address would be needed.
To aid in the decision for which way to go (add a new app service, recycle/reuse an existing one), consider the following when reconfiguring the parameters of the service to meet the needs of each operation:
- UI user requests are typically - but not always - smaller in terms of memory and CPU processing than XOG requests.
- UI user requests typically need higher amounts of concurrency with respect to threads than XOG requests. E.g. you could have 200 active user sessions on an app server for UI requests, you would probably expect many less (maybe less than 10 or 20) concurrently for XOG requests. Note also that XOG requests should be more diligent in performing explicit logouts from the application, reducing the amount of redundant session overhead being maintained that exists for web UI users who are logged in but inactive (reading content, closed their browser, otherwise distracted).
- Each implementation is different so if there is existing data that can be profiled from the app-access logs, this might paint a more accurate picture. Note that XOG requests are depicted in app-access logs as coming through the /niku/xog servlet, and user UI requests will use the others (/niku/nu, /niku/app, /niku/odata, etc.).
Where changes are likely to be made are in the JVM heap memory determined by the -Xmx parameter or in the maximum number of threads value, if not already adequate with their default values.