| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Performance of Z/OS MQ 6.0 Client Attachment Feature (CAF) |
« View previous topic :: View next topic » |
| Author |
Message
|
| Roadie |
 Posted: Mon Jan 08, 2007 11:13 pm Post subject: Performance of Z/OS MQ 6.0 Client Attachment Feature (CAF) |
 |
|
Newbie
Joined: 21 Aug 2006
Posts: 8
|
I am interested in learning of customer experiences with using the MQ 6.0 Client Attachment Feature on Z/OS regarding performance, resource utilization, and scalability of client connections.
I have heard rumor that previous versions of CAF were not very desirable to use (am unable to provide specifics). If the rumors have some modicum of truth, I am interested in knowing whether MQ CAF 6.0 is an improvement.
Thanks. |
|
| Back to top |
|
 |
| zpat |
| Posted: Tue Jan 09, 2007 12:40 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
We totally rely on the CAF (MQ 5.3.1 on z/OS) and have thousands of MQ client connections in production using TCP/IP (non-SSL). It is extremely reliable and we have no performance issues.
We compared client channel performance (CPU usage etc) to QM-QM channel and found it actually used less CPU than sending the same messages from distributed queue managers to the mainframe. Response time was lower as the topology is simpler. System management of distribued queue managers is eliminated.
I personally have no hesitation in recommending CAF at least up to 5,000 concurrent connections, beyond that I don't have personal experience but would suggest 10,000 is about the limit on a single CHIN address space (but you could run multiple QMs or CHINs on one mainframe). |
|
| Back to top |
|
|
| tleichen |
| Posted: Tue Jan 09, 2007 7:01 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
We did hundreds of client connections on a single zOS queue manager, with no adverse affects. I have to say that it does what it is designed to do. The main thing you must remember with client connections is that the client must initiate the connection. It cannot happen the other way. Also, as far as the economics of it are concerned, the client is free on most distributed platforms. 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jan 09, 2007 7:05 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Yes, the other thing is that MQ client based applications (connected to any platform QM) must be coded to cope with disconnections (mq rc 2009) and re-connect automatically to maximise their application availability.
I recommend developers to code a wait of 15 seconds before each retry of the MQCONN to avoid excessive network traffic during any QM downtime (or failover). |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 11, 2007 8:42 am Post subject: |
|
|
Guest
|
The MQ Client (any platform) imposes additional network flows between client and server for transporting the MQ calls - this in addition to the actual message flows. Accordingly, the client (not the Client Attachment Feature) is not a setllar network performer for very large and high volume messages. It works.
The mainframe, with all its horsepower and other resources, is a good platform for heavy client attachment loads. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
