Thanks to everyone who responded - >> >> IBM has TPNS, which can either work from network trace data, or you can >> create your own scripts. Also, I think CA has a product called Playback. >> >>Rick Tsujimoto
We don't have Playback; we might have TPNS.. I'll ask our systems people.. >> >> >>You didn't mention if this transaction requires a needs to use a terminal. I >>am assuming not since you're starting it up from a batch program. How about >>writing a simple CICS transaction that does a START for a whole bunch of >>transactions at once (well, OK, I guess they wouldn't be at once, but they'd >>be darn close). You could have it start up, say, 20 tasks and then just >>start it up 5 times to get your 100. You could even trigger it 5 times (that >>should be closer together than typing in the transid 5 times). Or maybe you >>could schedule them all for the same future time using the EXEC CICS START. >> >>Rebecca Bullock Yes I should have been more specific - actually, I'm not too concerned about MQ internals -> from xmit q to channel to channel to target queue is really fast, and I've seen the performance data. (In fact I just ran a batch test of 135 Puts and it took less than 1/100 of a second). I'm more concerned about the contention of 100 users all hitting enter at the same time and opening queues, putting messages and closing queues at the same time. I really am not sure also about the '8 TCBs' that MQ uses with CICS. I assume that means that eight MQ related transactions are active/swapped in at the same time, with the other 92 transactions swapped out.. ??? The GUI here is actually a hopped-up windows desktop application that formats the 'transaction details' into a data stream and sends it via a gateway to CICS where assembler/low-level programs translate the 'transaction details' into a call to a generic CICS program, which in turn calls the specific transaction. I shouldn't have to worry about that because we are modifying an existing program to call MQ, but to simulate that transaction I'd have to recreate the COMMAREA which is kind of long. I guess I could do that. >> >>To simulate 100 people sending messages at the same time, program your batch >>program to send all 100 messages in the same UOW. Tweak the channel batchsz >>and batchint to accomodate the entire UOW. The goal is to get the channel to ship >>some number of messages in a single UOW, such that they all become available >>at the same time. >> >>Dennis Miller >> I like that idea - it would make sure they all would be presented to the target at the same time. I'm guessing that they would actually be physically present on the xmit queue, but not visible to the channel (agent) until Committed? I'll put that in my batch program. I'll also pursue the online scenario outlined above. >> >>write one program to loop 100 times. have it start a simple cobol pgm that >>send a message to a round robin remote queue and then do a start with data >>on itself in an x amount of time. Have the start data contain the counter >>for the number of messages sent and check the limit in the started program. >>This is your termination data. Have the target queue of the round robin >>triggered to start amqsget or just leave the stuff the and do a CLEAR queue >>or something. >> >>this is about 1/2 hour of coding or about as much time as this thread has >>occupied. What I'm saying is there only one simple way to accomplish if you >>don't have a stress test package in place and are VERY familuar with it. >> >>bobbee ok, I'm still having trouble with this one. Maybe I need more coffee. A 'shell' program loops for 100 times.. In each loop it starts an MQ program that does a Put, and does a start of a third program? why is there a timer? Why not have a shell program loop 100 times to start an MQ program that does the open, put and close? Does this keep them independent (not single-threaded)? Or are you saying there is a way for all these started MQ progams to just wait out there until all 100 have been started (by each one looking at the message counter)? And then they would all take off at the same time? By the way, this is a roundtrip -request/reply, and I am matching on CorrelId. >> >>Depends on what you are really trying to load test. Is >>it the load on CICS or on your MQ network or on the >>Windows application? >> >>There are a number of testing tools for CICS (or at >>least there were a few years). CA's Playback. I think >>they also acquired CICS Verify so that product >>probably doesn't exist any more. Compuware had a >>product called Hiperstation - maybe called >>QAHiperstation these days. >> >>If it is the MQ testing that is important to you then >>take a look at CommerceQuest's MQTester and >>Compuware's QACenter for WebsphereMQ. >> >>mqm Actually, I am testing the Windows application load also, just because there is triggering involved, and the Windows app is a COM+ component, so I have to trigger an EXE which will then call the COM+ component. I wrote the EXE, and unfortunately it is generic so it is a little slower than it could be. I have tried using the IBM Support Pack for COM and SOAP, and it is actually a little faster than my method. If this turns out to be the bottleneck, I'll dedicate the target queue/triggering to this application and use the SOAP support pack. As far as the mainframe, we did have Hyperstation (for Y2K), but its gone now (in our Compuware purge). We can't buy anything for this testing.. Peter From: mqm mqm <[EMAIL PROTECTED]> on 01/31/2003 07:09 AM Please respond to MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: Volume testing of CICS requests Depends on what you are really trying to load test. Is it the load on CICS or on your MQ network or on the Windows application? There are a number of testing tools for CICS (or at least there were a few years). CA's Playback. I think they also acquired CICS Verify so that product probably doesn't exist any more. Compuware had a product called Hiperstation - maybe called QAHiperstation these days. If it is the MQ testing that is important to you then take a look at CommerceQuest's MQTester and Compuware's QACenter for WebsphereMQ. mqm --- Peter Heggie <[EMAIL PROTECTED]> wrote: > How do people simulate/perform volume testing of MQ > roundtrips that start > and end in CICS? Messages go to Windows and back. We > want to simulate CICS > transactions that send one message at a time, so > each iteration would do an > MQPUT1. > > Is there a way, without having 100 people sitting at > 100 CICS terminals and > hitting enter at the same time, of simulating a load > on the system? > > I'm writing a batch program to loop through a file > full of requests, but > still that is only sending messages one at a time.. > I can't run more than > two or three batch jobs at a time.. > > 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 __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com 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 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
