Number of threads/processes per site.

Thomas.

I can’t provide answers, as so much depends on the volume of messages and complexity of translation, but this is our setup on AIX.

Our largest production site has 26 connection threads and we have had no issues running this in Cloverleaf 3.5.5, 5.2.1 and 5.4.1 (AIX 5.3).

Our largest test site has 65 connection threads.

We are not a high volume site, with our largest production site (above) processing ~50,000 messages per day.

>The old rule of thumb was 6 to 8 threads per process ..

This may well be a high volume site ‘rule’ – even on 3.5.2, we had process (in test) with 20+ threads.

Our setup is for one Cloverleaf site to connect to one application and we have, in production, just under 60 sites/processes, down from 70+ before various application consolidation projects completed.

We don’t bounce our sites on a regular basis – we have housekeeping tasks and closely monitor the sites – they are bounced when required for a change or we test server failover.

If one of our sites continually failed for no obvious reason, I would suspect that we have reached a ‘limit’.

We are on LPAR’s and provided Tech Services with realtime production feeds so t hat they could ensure our servers had enough grunt.

With newer hardware you can push your threads per process count quite a bit higher.  One of our smaller servers has 34 sites including our two largest sites, and is 7 years old running AIX 5.1 with quads and 4GB.  Our two largest sites have 110 and 101 threads in 5 and 4 processes respectively broken out as follows.

Site #1

Process #1 (LIVE)  51 Threads

Process #2 (ADT)   17 Threads   (1 IB to 16 OB)

Process #3 (FTP)   5 Threads

Process #4 (TEST)  30 Threads

Process #5 (TEST2) 7 Threads    (Specialized ODBC stuff)

Site #2

Process #1 (LIVE) 51 Threads

Process #2 (ADT)  12 Threads (1 IB to 11 OB)

Process #3 (FTP)  5 Threads

Process #4 (TEST) 33 Threads

We found that with very high volumes we faired better not dealing with inter-process communication so we group threads accordingly.  The exception is with FTP related threads which use to have latency issues and in turn blocked the process.  In our really large sites we have also segregated our ADT feeds to a seperate process to ensure they do not impact our clinical interfaces since some or our facilities do huge month end ADT batches which would delay clinical messages.  This server averages in the 600K messages a day range and has a total of 1540 threads (not including cmd and xlate).  We have 6 other prod servers with another <200 sites the busiest with over 1.1 million msgs a day.  Enterprise wide we do over 4.3 million messages a day though <12K threads.

Obviously as Richard stated everything depends on what your interfaces do to the data, we use mostly raw routes with no data manipulation.  If you have ODBC, FTP or very complex translations you can’t stack your threads this deep but depending on the speed of your processors you probably can get to 15-20 threads per processes.  As you start increasing your size watch your message latencies to determine when you should start dividing your threads into more processes.

Jonathan Hamilton