| Author |
Message
|
| edwarm4 |
 Posted: Tue Mar 08, 2011 4:56 am Post subject: MQ performance |
 |
|
Newbie
Joined: 08 Mar 2011
Posts: 6
|
Hi,
I am new to MQ and have some concerns regarding the potential performance of a new mainframe COBOL DB2 program I will be building. I understand there can be significant performance overheads with connecting and disconnecting from MQ manager and opening and closing message queues when a COBOL program is initiated many times. The new COBOL program will be invoked by a Message Broker transaction and there maybe up to several thousand transactions a second.
Is there a way of having queues permanently open so that I avoid the overhead of connecting and disconnecting from MQ manager and opening and closing message queues ?
Thanks |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Mar 08, 2011 5:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You say that the cobol program will be invoked from Broker.
You mean using CICS? Or IMS?
CICS handles connections for you, your programs don't and can't make their own connections.
I don't know for IMS. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 08, 2011 6:35 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I am new to MQ and have some concerns regarding the potential performance of a new mainframe COBOL DB2 program I will be building. I understand there can be significant performance overheads with connecting and disconnecting from MQ manager and opening and closing message queues when a COBOL program is initiated many times. |
It seems that you are also new to mainframes, too. Correct? zSeries hardware usually has horsepower and (virtual) storage in abundance.
| Quote: |
| Is there a way of having queues permanently open |
No.
| Quote: |
| so that I avoid the overhead of connecting and disconnecting from MQ manager and opening and closing message queues ? |
Overhead implies waste. Connecting to a qmgr is a pre-requisite to opening objects. Opening objects is a pre-requisite to get/puts to a queue. Neither of these is a waste. But your app can (and should) be written to minimize MQI calls where possible.
You will need to tell us more about the application you are developing. For example:
What do you mean by many times? 10 times per-second? 10,000 times per-second?
Does the app consume one message, then end itself? Or does it remain connected with the queue open for a longer period - even if the queue is empty - waiting for another message to arrive (MQGET with WaitInterval?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| edwarm4 |
| Posted: Tue Mar 08, 2011 6:43 am Post subject: |
|
|
Newbie
Joined: 08 Mar 2011
Posts: 6
|
| We are not planning to use CICS or IMS. The COBOL programs will be DB2 stored procedures accessed directly from Message Broker via an ODBC/DB2 connection. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 08, 2011 6:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| edwarm4 wrote: |
| We are not planning to use CICS or IMS. The COBOL programs will be DB2 stored procedures accessed directly from Message Broker via an ODBC/DB2 connection. |
Then you need to look at how DB2 lets you cache connections.
Or write your own logic to check if you need to reconnect.
Or revisit why you're doing MQ access inside a stored procedure, and not using two-phase commit instead... What logic is being done in the COBOL program that needs to stay inside the COBOL program and can't be accomplished as a broker flow instead? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 08, 2011 6:53 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
So, how many db updates that call the COBOL-with-mq-calls per second?
How many calls do think will be too much overhead?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| edwarm4 |
| Posted: Tue Mar 08, 2011 7:02 am Post subject: |
|
|
Newbie
Joined: 08 Mar 2011
Posts: 6
|
Hi Bruce,
The COBOL program which will be a DB2 Strored Procedure which can be invoked upto 5,000 times a second. The app will check for a message on a queue, if none exists it will wait for a specific amount of time before continuing processing. |
|
| Back to top |
|
|
| edwarm4 |
| Posted: Tue Mar 08, 2011 7:09 am Post subject: |
|
|
Newbie
Joined: 08 Mar 2011
Posts: 6
|
| The SP will only be selecting rows from a DB2 table. Potentially up to a maximum of 5,000 reads per second. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Mar 08, 2011 7:41 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Only 5,000 per second?
If the LPAR is sufficiently provisioned, 5,000 transactions per second should not be a performance issue for WMQ or DB2 or your application.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 08, 2011 8:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I'm confused.
You said that the COBOL program was being run as a DB2 stored procedure, and that the COBOL program accessed MQ.
Then you said that the SP only selects rows from DB2.
Which is it? |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Mar 08, 2011 10:05 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| You can and should keep queues open for multiple gets/puts. This is down to the application that opens the queue. |
|
| Back to top |
|
|
| cicsprog |
| Posted: Tue Mar 08, 2011 4:22 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
I'm confused also on what you plan to do.
You might want to take a look at this doc:
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db2.doc.apsg/bjnqmstr12.htm
and these sub-topics from that url
WebSphere MQ with DB2WebSphere MQ messages
WebSphere MQ functions and stored procedures
Commit environment for AMI-based DB2 MQ functions and stored procedures
Single-phase commit in WebSphere MQ
Two-phase commit in WebSphere MQ
DB2 MQ tables
Converting applications to use the MQI functions
How to use WebSphere MQ functions
Asynchronous messaging in DB2 UDB for z/OS and OS/390 |
|
| Back to top |
|
|
| edwarm4 |
| Posted: Wed Mar 09, 2011 2:25 am Post subject: |
|
|
Newbie
Joined: 08 Mar 2011
Posts: 6
|
Hi,
Let me confirm what I am trying to do for each MB transaction which initiates the stored procedure :-
MB txn ---> DB2 SP ---> MQCONN
|
V
MQOPEN
|
V
MQGET using search criteria and wait time of
2 secs
|
V
MQCLOSE
|
V
MB txn <--- DB2 SP <--- MQDISCONNECT |
|
| Back to top |
|
|
| edwarm4 |
| Posted: Wed Mar 09, 2011 2:30 am Post subject: Required Functions |
|
|
Newbie
Joined: 08 Mar 2011
Posts: 6
|
Sorry my last post lost its original format. Please ignore this and look at the following for a functional representation of what I am trying to do:-
MB txn ---> DB2 SP ---> MQCONN ---> MQOPEN ---> MQGET using search criteria and wait time of 2 seconds ---> MQCLOSE ---> MQDISCONNECT ---> DB2 SP ---> MB txn |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Mar 09, 2011 3:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Broker handles MQ connections for you.
It will keep connections open for a reasonable period of time and only open new ones when needed.
You do not need to worry about this. |
|
| Back to top |
|
|
|
|
