Dennis,
It is really tricky to compare client/server
performance with server/server performance. I agree
that each application MQ client call would lose in
performance compare with application MQ server call
but I believe that the total throughput is better with
the client/server communication because the number of
I/O is low. The message is going directly to
destination queue within client/server without be
placed and retrieve on/from transmission queue.

Eugene

--- "Miller, Dennis" <[EMAIL PROTECTED]> wrote:

> The client connection has a performance
> disadvantage, mostly because of
> network overhead.  After all, every API request (and
> any messages it
> conveys) must pass over the network to get between
> the MQ client and the
> qmgr.  The server channel agent, acting on behalf of
> the client, uses
> local bindings and should experience about the same
> performance as the
> application using local bindings. But the exchange
> of API requests
> between the MQ client and the server channel agent
> is extra work.
>
> I am not in a position to quantify it, though, and I
> expect it would
> depend greatly on your network configuration.
>
>
> -----Original Message-----
> From: Gurney, Matthew
> [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 01, 2004 12:48 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Connecting to more than one queue
> managers on solaris,
> linux
>
>
> What would the performance difference of using
> MQClient connections to
> connect to a local Queue manager on the same Unix
> host, compared to
> using a local bindings direct connection to the
> local Queue manager.  I
> understand that for Pavel's situation, this be be
> irrelevant, but I am
> concerned with the general case?
>
> Matt.
>
> -----Original Message-----
> From: MQSeries List
> [mailto:[EMAIL PROTECTED] Behalf Of Miller,
> Dennis
> Sent: 01 September 2004 01:13
> To: [EMAIL PROTECTED]
> Subject: Re: Connecting to more than one queue
> managers on solaris,
> linux
>
>
> I understand your hesitance to use MQ client for
> such an app. But think
> about what you are really asking.  An app on one
> server with MQM
> credentials for other servers?  An app on one server
> with access to MQM
> internals on another server? Hmmm...
>
> I'm sure you know that without MQ-Client, you cannot
> even connect to a
> single QMgr across servers, much less multitudes of
> them. So, if your
> thinking about monitoring even one qmgr by an app
> running on a different
> system, you are talking about some sort of client
> model, by definition.
>
> But it needn't necessarily be the MQ client. You
> could for example,
> write a monitoring agent and run it locally on each
> qmgr. The user
> interface for your monitoring app is then a client
> to these agents,
> requesting services and receiving replies from them.
> If you are
> so-inclined, you can even conduct the request/reply
> exchanges using
> local connections and MQ messages (although,
> depending on what you are
> doing, one might question the wisdom of running a
> monitoring application
> in-band like that).
>
> It is somewhat analagous to how the command server
> works, only
> customized to your specific requirements.
>
>
>
>
> -----Original Message-----
> From: Pavel Tolkachev
> [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 31, 2004 1:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Connecting to more than one queue
> managers on solaris,
> linux
>
>
> Thanks Dennis,
>
> This is a low-level monitoring application
> (requiring mqm credentials,
> by the way). Making it an MQ client makes running
> listener or configured
> a pre-requisite to operate the app even if there is
> no business purpose
> for them to be there and creates a whole number of
> security issues with
> the too-far-going implications of their possible
> solutions. I will have
> to either live with these consequences or go for
> running several
> instances of the app instead (which is not ideal for
> my cause,
> either..).
>
> Pavel
>
>
>
>
>
>                       "Miller, Dennis"
>                       <[EMAIL PROTECTED]        To:
> [EMAIL PROTECTED]
>                       OM>                      cc:
>                       Sent by: MQSeries
> Subject:  Re: Connecting
> to more than one queue managers on solaris, linux
>                       List
>                       <[EMAIL PROTECTED]
>                       n.AC.AT>
>
>
>                       08/31/2004 04:05
>                       PM
>                       Please respond to
>                       MQSeries List
>
>
>
>
>
>
> Yes, you can do it in the server app. Just use the
> MQ client.  A server
> app from the perspective of the application
> architecture can be a client
> from the perspective of MQ.
>
> -----Original Message-----
> From: Pavel Tolkachev
> [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 31, 2004 10:30 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Connecting to more than one queue
> managers on solaris,
> linux
>
>
> Thanks David,
>
> Is there absolutely no way to do it in the Server
> app? What is so
> different between Windows and Unix that you can do
> it on one but not the
> other?
>
> Thanks,
> Pavel
>
>
>
>                       "David C.
>                       Partridge"                To:
> [EMAIL PROTECTED]
>                       <[EMAIL PROTECTED]        cc:
>                       RIMEUR.COM>
> Subject:  Re: Connecting
> to more than one queue managers on solaris, linux
>                       Sent by: MQSeries
>                       List
>                       <[EMAIL PROTECTED]
>                       .AC.AT>
>
>
>                       08/31/2004 11:58
>                       AM
>                       Please respond to
>                       MQSeries List
>
>
>
>
>
>
>
=== message truncated ===




__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Reply via email to