- This topic has 2 replies, 3 voices, and was last updated 17 years, 1 month ago by
.
-
Topic
-
Hello All, IBM P520
Dual processor
4 36 gig drives
AIX 5.2
Cloverleaf Platform V
Version: 5.3P_REV2
Our current production and test sites have 10 process with a total of 50 threads each and are on seperate identical boxs. One process contains 2 thread that simply uses Cloverleaf as a go between two systems. The messages are sent raw there is no translating or filtering involved.
Another process contains 3 threads and is temporay that sends a burst of data once a day. The remaining processes vary in thread count but contain no more then 8 threads.
The question I have is can I add another process and about 6 threads to site.
2 threads would be a inter-process connections.
One thread is raw and second would do the Xlating and routing
2 thread for result translations from our Laboratory and Radiology systems
these also would be inter-process doing routing and Xlating.
1 thread for ADT
again inter-process
1 thread for MFN.
again inter-process with minimal traffic on this thread less then 100 transaction per day.
The old rule of thumb was 6 to 8 threads per process, which includes the command and Xlate thread but I unaware of any process limits.
Has the thread limit per process increased under Platform V? In addition, how can I determine if I am reeaching the max for on lock manager and monitor deamon.
My thinking is to add the process as a quick fix to feed the new clinical system (Epic) with ADT, results, and MFN data in phase one. Giving the integration group time to develop a new design strategy going foward.
-
Replies
-
-
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
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
