Any standard for number of sites, processes, threads in single Cloverleaf server

IMO the max number of sites per server depends on the size of the server. I do not know of any built-in Cloverleaf limitation to the number of sites. At the last place I worked as an employee we had around 300 sites on one server without issue. we had a big AIX server though.

There can be a monitoring concern with multiple sites which then directs one’s attention to Global Monitor for assistance.

I think the number of processes per site is dependent on a number of factors like how busy each process will be and the number of CPUs available for the processes to be allocated to.

We tried to keep our thread count per process to 10-12 max depending on the purpose of the site. Many of our sites only had one process and some processes had less than 10 threads by design.

There can also be a monitoring concern for environments with fewer but busier sites.

Also consider you only get one Recovery DB per site – one site one Recovery DB, multiple sites multiple Recovery DBs.

So while I believe there are some guidelines I do not believe this is a cookbook situation.

I think each environment’s architecture will depend on what is best for that environment.

I personally subscribe to the multiple site architecture as a basis.

We used a distribution site architecture.

As an example

a primary ADT ‘Receiving’ site (received the ADT messages from the ADT system)

The primary ‘Receiving’ sites had one process with a limit of 11 OB threads.

Each of the OB threads connected to another site – Called the ‘Delivery’ sites.

the Receiving Site’s only job was to apply any global IB Tps procs then raw route ALL messages to each OB thread (a Delivery site).

The ‘Delivery’ Sites each typically had one process (some had more but not many more) and that process had a maximum of 11 OB threads which were typically destination systems. Here is where message filtering, transformation, etc. would take place.

So as I recall we had slightly more processes than sites because some Delivery sites had more than one process. Maybe 320 processes.

The above is a simplistic view – we did have some specialty integrations which required their own somewhat different architecture but most everything was expressed in the Receive Site/Delivery Site Architecture.

Our system size was dictated more by the volume and size of messages we integrated (nearly 7 million per day in 2015 and some of them very large) than by the site architecture.

Having multiple Recover y DBs as a result of the multiple sites was a plus for us.