Intrasite cross proccesing routing

Aesthetically speaking, if you have a busy NetMonitor and need to drill down by process, you lose the routes for things between processes.  However, you can get around that with views if you remember to use them.

Performance wise, you’re adding extra hops and points of failure, so that’s a problem.  However, on 6.0, we ran into issue when a process gets a huge load of messages, for the thread outside the process, the messages queued up in state 5, while all those in the process, messages marched along to the outbound threads, state 11.

I’d like to hear more about this because we are working through this now with a large project.

I have an interest with this subject as well.

We have designed our entire interface engine with the overriding idea of NO CROSS PROCESS threads, so we have ALOT of hops, both intra and inter site.

Gets really confusing sometimes.

I also get when looking at a “process” view, you would NOT see the “other” process associated to the viewed process.

So you would need to take this into account when looking at views.

Bottom line.. It was a problem, it is still a problem?

We are looking at a possible re-design for our 6.2 upgrade coming in 2018

Thanks in advance.

Back in the day of YH2K, slow servers and limited resources, it was preferred to keep IB and OB threads in the same process. Level I class taught the concept of “NO CROSS PROCESS.” Since then, Quovadx spent quite some time reworking and improving the inter-process communication.

Since 5.0, I’ve had a lot of success avoiding the bottle neck of the IB/xlate/OB thread groups and unneeded TCP/IP hops by moving all OB threads to their own process and keeping IB/xlates limited in their through put. We even have multi-thread xlates to improve that bottle neck.

I do not worry about the clumping of IB/OB threads by process, I use groups and views to manage that perspective. I don’t like over burdening the engine with extra hops and recovery writes because some users unfamiliar with the more dynamic aspects of the tool. Clvf is an awesome engine when it’s used well. There’s a lot of “old” knowledge that just does not apply anymore, but I see it in use all too often. Just my two cents…

Steve; that is what I thought.. The reasoning (No Cross Process) is because it WAS that way, but now, there is a better way to do it.

Thanks for the response and confirming my suspicions concerning this subject..

Now for a redesign..

For what it’s worth …

We tested both methods recently on CL 6.2.0.1.  Inter-process communication worked very well at normal message volumes.  When we stress tested the system, they bogged down.  At extremely high message volumes, inter-process communication took an order of magnitude longer than using IP hops.

I prefer not to use IP hops because of the Recovery Database overhead, new message ID’s, etc, but it’s hard for me to argue against better performance.

Funny… I have been working on QDX for many years, and never heard this theory, until six months ago.  I have managed many cross process threads, without jumping hoops, without these identifiable issues.

I have most processes set up as non-cross processes for the ease of switching a process to a back up site, if one of the characters is misbehaving.  

So if I have a corrupt thread, or add something new, that is not behaving as I expected, I can stop that process and start it on my back up site, until I can trouble-shoot that process problem.  

This has proven, time and again, to be a great asset of non-cross process threading.        

My two cents.

My $.02

Since the process schedules threads to run much the same as the OS schedules processes to run, it makes sense if you put a *LOT* of threads in a process a given thread will not run as often.

With that said and given just a couple of threads with normal HL7 messages, the only difference between inter-process and intra-process is the way messages are passed between threads.

With inter-process the entire message must be passed within memory.  With intra-process only the memory location (4 bytes, I think) is passed.

So given normal sized messages of a couple of hundred bytes you would probably not notice a difference.  If you are passing very large messages of course you will see a difference.

The bottom line is, for most of the implementations I have seen or done, intra vs inter process is best used for ease of maintenance and not for throughput.

Again, just my $.02 worth and you would probably get change with that  😀

More pennies for consideration.

Back in 2013 with v5.8, I did a special high performance test using millions of “normal” sized ADT (250 – 1500 byte) messages to test three possible route scenarios within the engine. One was using TCP/IP hops, the second using a recirculating thread where OB msgs are flipped over to the IB queue using a TCL script, the last used inter-process routing. Then, as a lark, I added a forth route set using file based hops. No translation was being done to the messages in any scenario, just raw routing.

The system was windows based with 6 processors, 16 GB Ram and two high speed SATA-III SSDs in a RAID 0 Configuration (no fiber channel).

The results were strange in that the file based hops were significantly faster, around 10%, than the TCP/IP hop, and the TCP/IP hops were faster by about 2% over the inter-process routes. The recirculating thread model routes were the slowest. I retested the scenarios multiple times with different data sets and the results were consistent on that platform.

Now, understand that the through put was extremely high as each test took between 40-45 minutes. So, without other factors, like very large messages or lots of xlates, I found each method to be “on par” with each other. I have deployed the recirculating thread model many times when it made the most sense. even though it’s the slowest performer.

Although I’ve never deployed file based hops in production, I did find that the result the most interesting.

Since Infor added the thread recirculation feature directly into the engine, I have not reproduced this type of through put test.