This was a very interesting discussion
- I learned from it!!
As our TIBCO layer is a JMS layer, it
was already performing to spec and adding the ID: to the front of the correlation
id when issuing the get - COOL!!
But, as noted by T-Rob, the v7 behavior
is controlled by other factors, and so we have set the SHARECNV attribute
to 10 on the SVRCONN channel, and we made the .bindings file change to
add the PVER attribute. Just doing this increased our throughput
quite dramatically, somewhere between 15 and 20 %. What's left now
is to test throughput with deep queue depths - we'll see how well that
goes next...
Stay tuned...
Thanks,
David Corbett
IBM WebSphereMQ v6 Certified Administrator
From:
T-Rob <t.rob.wyatt-rIXRsD/jSGdXrIkS9f7CXA@public.gmane.org>
To:
MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org
Date:
02/07/2012 11:18 AM
Subject:
Re: Client performance
across the WAN
Sent by:
MQSeries List
<MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org>
Whether property-based selectors are selected by the
client or the QMgr in
v7 depends on the configuration. I *believe* that SHARECNV,
PROVIDERVERSION and BROKERVER are the relevant properties but it's not
something I use frequently. I know the intent was to move as much
as
possible the selection into the QMgr but also to fall back to something
that worked as before where the optimization is not possible. Perhaps
someone more familiar with those aspects will respond.
-- T.Rob
MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/W97FXqFh9Ls21Oc@public.gmane.org> wrote on 02/07/2012
11:40:47 AM:
> From: George Carey
> To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/W97FXqFh9Ls21Oc@public.gmane.org
> Date: 02/07/2012 11:43 AM
> Subject: Re: Client performance across the WAN
> Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/W97FXqFh9Ls21Oc@public.gmane.org>
>
> I did see the info in IBM doc about prefixing 'ID:' for MessageID
or
> CorrelationID usage and not otherwise. The gained performance
> improvement, mentioned by Petr P., would likely have been missed,
however.
>
> On T-Rob's note ... "If in fact the field is evaluated in the
JMS
> client instead of the QMgr ... and selecting as for JMS properties.
> Of course, even that gets moved to the QMgr in v7.0 and later in
> 'many' cases."
>
> On the 'Of course ...(sentence)', Dave stated he is using v7 qmgrs
> and client, "The QMGR is on LINUX RHEL and is currently at 7.0.1.2.
> The clients are at 7.0.0.2.", shouldn't Dave have then seen those
> performance benefits, mentioned or must you use 'ID:' prefix to see
> the performance benefit for true MessageID and CorrelIDs 'gets'
> regardless of the version?
>
> GTC
>
> -----Original Message-----
> From: T-Rob [
mailto:t.rob.wyatt-rIXRsD/jSGdXrIkS9f7CXA@public.gmane.org]
> Sent: Tuesday, February 7, 2012 10:11 AM
> To: MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org
> Subject: Re: Client performance across the WAN
>
> It's part of the JMS spec. From Section 3.4.3 JMSMessageID:
>
> All JMSMessageID values must start with the prefix ?ID:?.
>
> Then in 3.4.5 JMSCorrelationID
>
> In some cases, an application (made up of several clients) needs to
use
an
> application-specific value for linking messages. For instance, an
> application
> may use JMSCorrelationID to hold a value referencing some external
> information. Application-specified values must not start with the
?ID:?
> prefix;
> this is reserved for provider-generated message ID values.
>
> So if you use ID: then it's a true JMSCorrelationID and mapped to
the
MQMD
> correlation ID which WMQ will natively use for selection. If
in fact
the
> field is evaluated in the JMS client instead of the QMgr then it follows
> that WMQ would be treating it as an application-defined field and
> selecting as for JMS properties. Of course, even that gets moved
to the
> QMgr in v7.0 and later in many cases.
> -- T.Rob
>
>
> MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/W97FXqFh9Ls21Oc@public.gmane.org> wrote on
02/07/2012
> 07:56:41 AM:
>
> > From: "Potkay, Peter M (CTO and Service Mgmt)"
> > To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/W97FXqFh9Ls21Oc@public.gmane.org
> > Date: 02/07/2012 07:57 AM
> > Subject: Re: Client performance across the WAN
> > Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/W97FXqFh9Ls21Oc@public.gmane.org>
> >
> > It was so long ago I can't remember if I found it on IBM's site
or if
it
> > was thru someone's help here or on
www.mqseries.net.
But tracing and
> > Transaction Vision confirmed the before and after MQGMO options
being
> > used by the JMS client by making this simple change in their
code.
> >
> > Peter Potkay
> >
> >
> > -----Original Message-----
> > From: MQSeries List [
mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org]
On
> > Behalf Of George Carey
> > Sent: Monday, February 06, 2012 6:20 PM
> > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org
> > Subject: Re: Client performance across the WAN
> >
> > That's a keeper tip! Just curious did you read this from doco
or was
> > this from empirical testing?
> >
> > GTC
> >
> > -----Original Message-----
> > From: Potkay, Peter M (CTO and Service Mgmt)
> > [
mailto:Peter.Potkay-rD8JZfJvD73NW2jkNpEmTg@public.gmane.org]
> > Sent: Monday, February 6, 2012 06:01 PM
> > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org
> > Subject: Re: Client performance across the WAN
> >
> > Dave,
> >
> > For JMS clients, they are doing a browse of each message, bringing
the
> > entire message back each time, and finally doing a destructive
read
once
> > they see the copy they want.
> >
> >
> >
> > By doing a get with an "ID:" thrown in front of the
Hex Value of the
> > desired Correl ID, you make it act like classic MQ where the
Queue
> > Manager does the selective get for you and only returns the matching
> > message. This will perform waaaay better for deep queues and
long
> > distances.
> >
> >
> >
> > It needs to be "ID:HexValueOfTheDesiredCorrelID" when
preparing the
> > selective get. You can do this for selective gets for Message
IDs too.
> >
> >
> >
> > Peter Potkay
> >
> >
> >
> >
> >
> > From: MQSeries List [
mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org]
On
> > Behalf Of Dave Corbett
> > Sent: Monday, February 06, 2012 5:15 PM
> > To: MQSERIES-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org
> > Subject: Client performance across the WAN
> >
> >
> >
> > Listers,
> >
> > I have a scenario where I have a QMGR in one data center and
MQ
clients
> > in another datacenter. The clients are actually in both
datacenters,
> > but depending on what needs to come down when for maintenance,
or
> > possibly even due to failure on the client side, we might have
all of
> > the activity being handled in the remote datacenter. All
of these
> > clients are performing a get with Correlation ID, and what happens
is
> > that under load, when the queue depths start to be non-zero,
the
> > performance is drastically reduced.
> >
> > I am pretty sure the reason is the the client is reading all
messages
in
> > the queue across the WAN, deciding which one it wants and ignoring
the
> > others, and then reading all of the messages again for the next
message
> > it wants, etc.
> >
> > The QMGR is on LINUX RHEL and is currently at 7.0.1.2. The
clients
are
> > at 7.0.0.2. I am more than willing to upgrade to newer
version at
both
> > ends, but was wondering if this is a known behavior and if it
has
> > changed in the later versions. I am not convinced that
I want to turn
> > on client read ahead (in fact, I don't know if I can as this
is TIBCO
> > clients using JMS), but the messages are non-persistent and they
would
> > technically fit this model, but the reduced message assurance
of
> > delivery always makes me nervous.
> >
> > I haven't configured the shared conversation mode on the SVRCONN
yet,
> > but I will be testing again with that set to 10 - I am just wondering
if
> > purely a Client / QMGR upgrade will resolve this performance
issue by
> > having the QMGR perform the search and only send the requested
message
> > back to the client. As usual, I try to find information
like this on
> > the web,
> >
> > Any help is appreciated.
> >
> > Thanks,
> > David Corbett
> > IBM WebSphereMQ v6 Certified Administrator
> >
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org and,
> in the message body (not the subject), write: SIGNOFF MQSERIES
> Instructions for managing your mailing list subscription are provided
in
> the Listserv General Users Guide available at
http://www.lsoft.com
> Archive:
http://listserv.meduniwien.ac.at/archives/mqser-l.html
>
> To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org and,
> in the message body (not the subject), write: SIGNOFF MQSERIES
> Instructions for managing your mailing list subscription are provided
in
> the Listserv General Users Guide available at
http://www.lsoft.com
> Archive:
http://listserv.meduniwien.ac.at/archives/mqser-l.html
>
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+2wyY2g16FtwPuJ0ROkVbw@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at
http://www.lsoft.com
Archive:
http://listserv.meduniwien.ac.at/archives/mqser-l.html
U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.
---------------------------------------------------------------------
List Archive -
Manage Your List Settings -
Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
RSS Feed