Chain and Branch consideration

[Shane Farney]

I’m trying to find any information on Chain and Branch features of the NetConfig routing and whether they in any way improve performance.  Has anyone had some good experiences where these features improved performance at all?

For a scenario to consider, we have an inbound ADT that is starting to slow down where we are receiving more messages than can be processed at midnight.  Messages come in, queue up in state 5 and I’d like to make it faster.  We have 8 routes coming off of the one inbound, all are raw, but have 3 proc tps filters on each route.

Topic

[Jim Kosloskey]

I  don’t believe chaining by itself will afford any performance enhancement.

I have used it when I needed to ‘stack’ Xlates. While I saw no obvious degradation I also observed no enhancement to throughtput.

Branching as I understand it is really intended for the situation where it is desired to have all the messages inbound ‘normalized’ prior to any real transformation. In that situation the potential to improve performance exists I think. I am not so sure that satisfies you scenario though.

I personally have never deployed branching other than in an experimental test.

Perhaps the issue is better addressed at the source system. Why is a ‘dump’ of real time messages happening in a real time environment?

Are the messages actually of use down stream?

If they are needed downstream, are identifiable, and are not time dependent, perhaps routing the messages unfiltered to a Fileset Protocol to be picked up later under controlled circumstances where throttling can be applied might improve things.

The best outcome would be if during that time, the sending system could ‘pace’ the messages to a more acceptable arrival rate – or not send at all (if not needed downstream).

Others may have faced this same situation and hopefully will provide their insight as to how they handled it.

 

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[Shane Farney]

Thanks for your input.  The splurge of messages are from batch processes, closing out encounters.  Some systems need this data, though we’re starting to think maybe not real-time and could go to the back of the line.

Your idea about delaying them somehow is also on the table in our discussions.  We’re considering changing priority of messages identified by the nightly batch process… to give the real-time messages more of a fast-lane.  Do you guys play with priority on messages at all?

[Author]

Replies