ChrisHoelscher

z/IIP-itty doo dah  - my R18 vs. R17 comparison - part I

Discussion created by ChrisHoelscher on Nov 13, 2012
I wanted to share my R18 exhaustive? Tests so that you might decide of z/iip is right for you

On my first comparative environment:
No ads/O, no DC-COBOL - only a IDMS and CICS BACKEND - anywhere from 60-100 million tasks/week

RELEASE

17

18

18

18

% improvement

%improvement

FIXES?

n/a

no

yes

yes

over

w/o

STATS?

NO

yes

yes

no

r17

stats

#tasks

67011088

84466001

89866993

85705747

total

0.000899000

0.001102500

0.000969800

0.000885639

1.486261135

8.678231347

tcb

0.000008990

0.000001100

0.000004600

0.000006214

srb

0.000890010

0.001101400

0.000965200

0.000879424

not sent to ziip

0.000593340

0.000550700

0.000482600

0.000439712

sent to ziip

0.000296670

0.000550700

0.000482600

0.000439712

refused by ziip

0.000000000

0.000000000

0.000000000

0.000000331


total ziip

0.000294000

0.000550700

0.000482600

0.000439381

49.449217993

8.955511625

total nonziip

0.000604800

0.000551800

0.000487200

0.000446258

26.213984821

8.403567363


A few notes - these numbers address only the internally generated info from IDMS - this is not the information that our performance folks use for their purposes, but it is what I used to compare IDMS R18 VS R17 performance (ziip and otherwise)

As to not bore anyone with numbers - here are the results

Overall:
Total cpu reduction was less than 2% improvement over R17 (no improvement was implied nor expected)
As in R17 there was a slight amount of code determined to be TCB mode that was not eligible for ziip assignment
Of the remainder - 50% in R18 (vs. 33% in R17) of SRB code was routed to zIIP processors
Less than 1/10th of 1% of work sent to ziip was refused by ziip (not release dependent - consistant with R17)

And the category that matters most - non-zIIP (billable) cpu reduced in R18 by over 25%

Another important (to me at least) fact was that turning stats off reduced all cpu by over 8% ( I did this primarily to compare to R17 since that's the way we ran in R17) - however - our performance folks are implementing a chargeback system and I can't convince them to sample (1 or 2 weeks/quarter) - so we will be burdened by the overhead.

A few notes - ASK CA for EVERY ziip-related fix - published or otherwise - it WILL make a difference
The longer you can leave a CV up (weekly or monthly vs. nightly) - the better cpu/task will get - (as iOs become buffer reads (hopefully) and startup overhead gets distributed over more tasks ...)

I realize that this is a best-case CV for testing Ziip and not one that fits every site - however, it was for us the busiest - so I wanted to concentrate on this one to get the most "bang for the buck"

I wanted to give a big THANKS to John Siraco at CA who has worked with me other the past 6 weeks to smooth out all the road bumps in zIIP

Next up - comparing an USERCODE-centric IDMS CV - R18 vs. R17

Chris hoelscher
Technology Architect | Database Infrastructure Services
Technology Solution Services
[Description: Description: cid:image001.png@01CD13D7.1A57CAF0]
123 East Main Street |Louisville, KY 40202
choelscher@humana.com
Humana.com
Keeping CAS and Metavance safe for all HUMANAty



The information transmitted is intended only for the person or entity to which it is addressed
and may contain CONFIDENTIAL material. If you receive this material/information in error,
please contact the sender and delete or destroy the material/information.

Outcomes