| Author |
Message
|
| sfari |
 Posted: Mon Sep 25, 2006 7:32 am Post subject: High CPU load |
 |
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
Hi, I have been asked to make some tests with Java Clients connecting via SVRCONN Channels to the mainframe to check the CPU load.
I started 5 Senders which have sent each second a small message on a queue (9000 msg totally).
20 Listeners have been registred on the queue to consume this messages.
The test was running for 1/2 hour. All these clients connected using SSL once at startup an remained connected.
This small test consumed approx. 150 CPU seconds. This we get charged per CPU second this is quite alarming.
Is this normal that Programs, which connect as clients to z/OS need quite a lot of CPU? Has somebody any other experiences with this? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Sep 25, 2006 3:17 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20697
Location: LI,NY
|
You connect with SSL? Which portion of the CPU is consumed doing SSL (encryption/decryption)? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sfari |
| Posted: Tue Sep 26, 2006 3:14 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
Don't know exactly what you mean?
I am not the mainframe specialist, and the mentionend cpu laod gets consumed by a bundle of multiple mq relevant programs I assume it consists of channel initiator, queue manager, ...
The bundle is made by our provider, which is IBM. This bundle measures the load to calculate the cost for MQ in total.
Concerning SSL I can only say I have been told to configure TRIPLE_DES_SHA_US on the channel because it is supported by the mainframes crypto hardware.
Are there many of you using MQ Clients (e.g. Java) running against z/OS Queue Managers? What experiences have you made with it? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Sep 26, 2006 3:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Using SSL on the mainframe without using a cryptographic co-processor will have a noticeable affect on the CPU utilization of your channels.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sfari |
| Posted: Tue Sep 26, 2006 4:59 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
| That's exactly why I had to configure TRIPLE_DES_SHA_US. Mainframe people told me that because the cryptographic co-processor does support this cipher. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Sep 26, 2006 5:12 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
So you're not configuring the mainframe side, just the java client side?
Because there's more than just changing the algorithm to configure the crypto support hardware.
But, regardless, all client applications offload the MQ API processing to the server, what gets streamed back and forth across the network is the "data" -the api calls and the api results.
You may save a significant amount of licensing money by putting in a distributed queue manager on Unix or some such, having all of your client applications connect to that and use regular MQ networking to move messages back and forth to the mainframe.
You may also have to invest a good deal into getting the distributed queue manager to meet the reliability and scalability requirements you have, including setting up HA configurations and making sure that the distributed queue manager can handle the needed number of clients.
So it could balance out, costwise.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Sep 26, 2006 5:29 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
| Why use SSL if the client is on the internal network? |
|
| Back to top |
|
|
| sfari |
| Posted: Tue Sep 26, 2006 6:39 am Post subject: |
|
|
Centurion
Joined: 15 Apr 2003
Posts: 144
|
SSL within our company network is policy and we use it also for strong client authentication and based on that for authorization on queues.
@jefflowrey
Thanks for this answer. That't exactly what we are currently doing. There is a money saving project calculating a business case which is based on removing exactly these distributed queue managers. And saving their license and operation costs.
Because I had a bad feeling about this Idea I made the mentioned tests. So I am collecting arguments against it. I just thought there must be reasons the usual strategy is to move things out of the mainframe. I think it is mainly because of licensing model of paying per CPU-Second.
So I am happy for any more arguments I could use. Thanks! |
|
| Back to top |
|
|
| cicsprog |
| Posted: Thu Sep 28, 2006 10:54 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 314
|
Take a look at the IBM MP16 document. Topics are included for capacity/CPU consumption of MQ Clients attached to z/OS MQMs.
Your mileage may vary. |
|
| Back to top |
|
|
|
|
