IBM Mainframe Forum

I am not sure whether I should post in this forum. It is about the CICS pseudo-conversational application also about performance. I am doing workload test for a CICS pseudo-conversational application. I am confused by the test result which indicate that the CPU cost per transaction actually falls as the throughput increases., so does response time per transaaction. In my understanding, with the throughput increase, the response time should increase as well but the CPU time should keep unchanged. I do not understand the result also do not know how to explain it. Is there anyone familar with this kind of CICS applicaion? And is the result reasonable or not? Thanks in advance!

You haven't provided much hard data to review -- which is contrary to expectations since performance analysis usually is done with numbers. However, if the CICS region is not hitting maximum tasks then it is quite possible for response time and even CPU time to go down as throughput goes up. Once max tasks is reached, then I would expect response times to increase. CPU time may or may not increase as well.

Questions that come to mind:
1. How many tasks are you analyzing?
2. Where are you getting the performance data from?
3. Is the data being truncated (CPU time for CICS transactions can be recorded to six or more decimal digits; if you only look at 1 or 2 digits then you could be losing a lot of information)?
4. Are you analyzing data from multiple days at various times to account for cyclic discrepancies?
5. What are the CICS region configuration values (such as max tasks)?

Based on the little you've provided, the results you are seeing are entirely reasonable and possible. With more data, that answer could change but as it stands I see nothing suspicious or untoward so far.

Hi Robert,

Thanks for your response! Below are the answers for your questions. Please give your advice, thanks!

1.For the pseudo-conversational transaction, I recorded a business transaction scenario which consist of 8 CICS tasks using workload Simulator tool. Then specify a loop count of 100 around the business transaction in Wsim script. That is to say there will be 800 cics tasks executed for single user run. I have ever run 25U, 50U, 75U, 100U workload respectively to check the performance. Below is the workload VS CPU consumption.

Concurrent Users User CPU Time/task Tasks CICS CPU% System CPU%
1 0.00327 800 1 5.1
25 0.00227 20000 16.0 25.3
50 0.002269 40000 25.0 33.2
75 0.002244 60000 32.0 41.7
100 0.002231 80000 39.0 49.4

2. I used CICS Performance Analyzer to report the performance data. The CICS PA summary report can provide the average number for all tasks for each run.
3. See the numbers above.
4. My test will only last 10 minutes.
5. CICS configration
Maxtasks( 300 )

I pasted the data table again. Hope the format is correct this time.

the last 3 columns still does not align with the data,but basically can understand.
Based on these numbers, do you think I should run more workload above 100 users to get more larger throughput then see what happeded?

I'm not familiar with the package you're using, so I don't know how well it simulates a typical user -- for example, does it include think time between transactions or does it just bang all the transactions in as quickly as it could? Frankly, running through 80,000 tasks in 10 minutes is probably a much higher throughput rate than will be seen in production! I don't really see anything to be concerned about, though. Your tasks went from 800 to 80,000 (100 times) while CPU went from 1% to 39% (39 times), showing a non-linear growth rate. Unless you've got some specific concerns I'd say it is time to move on to other areas.

Further, you give max tasks as 300 but don't indicate if the region actually hit that number -- which is where I said the concern would be. After you do a test, you should enter a stat transaction to dump the CICS statistics. Hitting max tasks, running short on storage, running out of strings on your files -- these would be things to fix as they will impact your performance.