6 Replies Latest reply: Aug 21, 2014 1:09 PM by Todd Little-Oracle RSS

    Oracle Tuxedo /Q system alongside 6.0 version or higher

    Bruno Taboada

      Hi Todd Little-Oracle how are the things?

       

      My working team have two questions related to queues in Oracle Tuxedo.

       

      our team is wondering if Oracle Tuxedo /Q system at 12.1.1.1 version can interoperate with Oracle Tuxedo /Q system at 6.0 version. We are in doubt if a Tuxedo domain at 12.1.1.1 version have access or a way of using queues deployed in other Tuxedo domain at 6.00 version or higher. if so? how does it work?

       

       

      Another questions are in regard to pros and cons of having one queue per Queue Space or more than one queue in a single Queue Space? the reason why we ask that is we realized that production environment and development environment in our customer are deployed slightly different. In the developing environment, there is one Queue Space and all queues are in it but in the production environment has created one Queue Space for each queue.

       

       

      Could you provide theses insights and expertise for us?

       

       

      Thank you so much once again.

       

      Hope you are doing well.

       

      Best regards.

        • 1. Re: Oracle Tuxedo /Q system alongside 6.0 version or higher
          Todd Little-Oracle

          Hi,

           

          I'm well, thanks for asking!

           

          Regarding /Q interoperability, I'm not sure exactly what you are trying to accomplish.  If this is really across domains, then there shouldn't be a problem.  /Q uses the TMQUEUE servers to provide access to the /Q queues.  Those TMQUEUE servers are accessed via a service name that is the same as the /Q queue name.  The tpenqueue() and tpdequeue() API's simply call a service by the name of the queue space underneath the covers.  So you can support /Q across domains by importing the queue space name as a service name in the domain gateway configuration.  Since we support domain connections across Tuxedo versions, this "should" work, meaning, you or the customer should test this first.  Make sense?

           

          As far as queues per queue space, I think this is largely a scalability question.  Each queue space has one or more TMQUEUE servers that manages the queue space including all queues in it.  So if you have a single queue space with 5 queues in it and a single TMQUEUE server, then you can handle at most 1 concurrent /Q operations to those queues.  Had you defined those 5 queues each in a separate queue space, then each one would have its own TMQUEUE server meaning you could service 5 queue/dequeue requests simultaneously.

           

          I hope that helps!

           

          -tl

          • 2. Re: Oracle Tuxedo /Q system alongside 6.0 version or higher
            Bruno Taboada

            For now, we want to accomplish oracle tuxedo's features tests so we can better come to right decisions on our major problems and architectural decisions as they are going to require. In fact, it is cross domain configuration I was talking about. Sorry for not having mentioned it.

             

            Also, we have been diving into tuxedo so we can deliver better solutions and services on it.

             

            I hope I am not being annoying for you.

             

            Thank you for answering my questions you got the point I have asked you.

             

            Bye. See you tomorrow. Todd Little-Oracle

            • 3. Re: Oracle Tuxedo /Q system alongside 6.0 version or higher
              Bruno Taboada

                   Taking opportunity we discussed queue scalability, how about keeping one queue space per queue device file? are there advantages keeping one queue device file for each queue space? if so. briefly, what are the main pros and cons?

               

               

              Also, Thank you for having answered my questions until now Todd Little-Oracle

              • 4. Re: Oracle Tuxedo /Q system alongside 6.0 version or higher
                Todd Little-Oracle

                Hi Bruno,

                 

                No annoyance at all and I'm glad I am able to help.

                 

                Regards,

                Todd Little

                Oracle Tuxedo Chief Architect

                • 5. Re: Oracle Tuxedo /Q system alongside 6.0 version or higher
                  Todd Little-Oracle

                  Hi Bruno,

                   

                  This largely depends upon whether you are doing using persistent messages or transient messages.  For transient messages it doesn't really matter as the queue space file really just hold the queue space parameters and not the actual messages, so the file is used only very infrequently.  For persistent messaging however, every persistent message queued causes a synchronous write to the queue space.  So the question of scalability becomes one of the underlying file system.  If for your particular platform/configuration you can get more file system throughput by accessing multiple files instead of a single file, then having a separate queue space per queue makes sense.  However if your platform/configuration makes the separation of requests to different files immaterial with respect to performance, then it doesn't really matter.  Let me see if I can give some examples:

                   

                  Let's say your queue space is on a single SAS 7,200 RPM drive.  That would yield about 75-100 IOPs so your enqueue/dequeue rate is going to be below that.  Not very good.  If you move to 15K drives, expect about 200 IOPs.  To really improve things you need to switch to either RAID configurations (say RAID 5), or SSDs possibly also in a RAID array.  A RAID 5 array requiring 1000 IOPs will need enough drives to provide 2,500 IOPs at a 50/50 read/write ratio.  That will take ~25 7,200 RPM drives, or around 12 15K drives.  If you switch to SSDs, then the number of drives becomes significantly less.  Current SSDs provide 100,000 to over 1,000,000 IOPs, which makes IOP performance almost irrelevant.  :-)

                   

                  In any case, the issue is really IOP rate, so however your file system/hard drive subsystem is configured will determine the value of splitting queues across multiple queue spaces or single queue spaces.  However, one thing to keep in mind is that queues sharing a queue space also share a shared memory section that requires coordination, i.e., locking.  So having all your queues in a single queue space can increase the contention on the queue space, whereas having each queue in its own queue space reduces contention at the expense of more queue spaces to worry about and more TMQUEUE servers to have configured.  There are no real hard and set rules around what is best for all situations.

                   

                  Regards,

                  Todd Little

                  Oracle Tuxedo Chief Architect

                  • 6. Re: Oracle Tuxedo /Q system alongside 6.0 version or higher
                    Todd Little-Oracle

                    Hi Bruno,

                     

                    I just realized that I didn't completely answer your question regarding multiple queue spaces in a single queue device file.  Personally I don't see any advantage to doing that.  The whole notion of the Tuxedo file system came about I believe partially to better support raw devices early on that had better performance than the Unix file system.  With today's modern file systems and kernels, I don't see any particular value to placing multiple things in a Tuxedo device file.

                     

                    Regards,

                    Todd Little

                    Oracle Tuxedo Chief Architect