Clovertech

max recommended OB threds per IB thread

› Clovertech Forums › Cloverleaf › max recommended OB threds per IB thread

  • Creator
    Topic
  • January 18, 2020 at 5:45 pm #114919
    Stewart
    Participant

      What’s the maximum number of OB threads you should have for a single IB thread?  What is the best practice when the number of OB threads exceed the recommended?

      We have a single IB ADT feed from our EMR that is distributed to at least 50 OB threads.  Should interprocess routing be used in this case or is there another solution?

    • Creator
      Topic
    Viewing 4 reply threads
    • Author
      Replies
      • January 18, 2020 at 5:46 pm #114920
        Stewart
        Participant

          Adding email updates to this thread.

          • January 18, 2020 at 10:45 pm #114921
            Jim Kosloskey
            Participant

              There have been many discussions regarding this general topic on this forum (most of it probably in the archive). If you find those discussion threads there is a lot of insight as to what others think and have experienced.

              Infor has a best practices document which has some basics.

              Essentially this has more to do with the number of threads in a process (and by extension the number of processes/threads in a site) rather than any ratio of OB to IB threads.

              Having said that, a lot depends on your environment and the workload characteristics in the process(es)/site(s).

              Generally (and this is really general) I find 10 threads (combination of ib and ob) per process to be quite acceptable.

              Inter-process routing has other considerations as well (such as using cross-process versus ob thread from one process to ib thread in another process via tcp/ip ports). Consideration needs to be given if the licensing is thread count based.

              So, in my opinion, there is no real ‘cookbook’ response. One needs to do a thorough evaluation and architectural design as a result of the evaluation with future growth considerations in mind. Taking into account the hardware and O/S potentials as well.

              Sorry but I don’t think there is a quick and easy answer to your question.

              51 threads in a process (I am assuming here all of the threads you are using in your example are in one process) may work well in your environment for now or may be presenting issues which are not yet manifesting themselves externally.

              It is good though that you are taking a look.

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

          • January 20, 2020 at 10:55 am #114922
            Vince Angulo
            Participant

              Jim pretty much covered it.  Infor will always tell you anything outside of their best practices is not recommended, but it really all boils down to your hardware and OS.  If you were on Intel-Windows, I think those numbers would definitely be inadvisable.

              I don’t have your kind of numbers, we have a few inbounds that route to about a dozen outbounds each.  What works for us is having the inbound in one process and a ‘pass’ and its oubound in a separate process.  We’re on AIX with pretty beefy LPARS — using an unlimited thread licence.  Our daily inbound volume is less than 1M transactions, and we’ve been comfortable with this model.

            • January 20, 2020 at 10:59 am #114923
              Stewart
              Participant

                What is recommended by Infor in the event you have a large number of OB destinations from a single IB feed?  Should this be routed to a different process in the same site or should a new site be created with an intra-site port and then messages routed to this destination?

              • January 21, 2020 at 7:06 pm #114957
                Jim Kosloskey
                Participant

                  I don’t know if Infor has a recommendation or if it does what it might be.

                  Having said that, I think these are your options:

                  1. Place the IB thread (and potentially some of the OB threads) in one process and some or all of the OB threads to one or more other processes. Then inter-process routing under the covers will occur. This would not be my choice but this is your shop.
                  2. Do the same as above but use tcp/ip threads to connect the various processes together. I think this is what Vince alluded to.
                  3. Place the IB thread in a process in a site, the OB threads (some or all) in another site (and thus another process). This can be dine using inter-site routing (really inter-process routing under the covers) or by using tcp/ip threads out from the main site and matching in tcp/ip threads IB in the sites doing the delivery.

                  #3 above is the model we used at Oakwood to some degree and at MDACC more extensively. It worked best for our situation.

                  Again there is no real cookbook answer. You need to understand your environment, do some thorough analysis, and evaluate your future direction as best you can. There will be trade-offs no matter which way you go so you need to understand those and select the compromise that best fits your situation.

                  Personally I have maintained since around 1996 or so that every shop will be multiple site eventually. In my opinion it is a question of when not if. How you plan that will differentiate your shop.

                  Others may have additional and different insight.

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

                • January 22, 2020 at 10:27 am #114960
                  Vince Angulo
                  Participant

                    Again, great points by Jim.  Since you seem to have quite a few questions, I would suggest purchasing a block of implementation hours from Infor and have them provide direct guidance.

                • Author
                  Replies
                Viewing 4 reply threads
                • You must be logged in to reply to this topic.