Performance comparison ODA vs. AS/400 part 2

I wrote recently on comparing performance between a new platform and an old platform previously (here).  Note that this was comparing an OLD AS/400 with a new engineered appliance. This blog entry was a method by which you might be able to simulate a similar batch load on your new platform without having all of the users connected.

The article showed you how to generate the command line commands for running the batch load on your new enterprise server, create a script and away you go.

I ran this 5 times on the new platform and then gathered statistics from F986114 of both environments so that I could do an accurate comparison of the performance.

I cheated a little bit, despite having database links to the AS/400, I decided to do some number crunching in EXCEL.

Above is what the spreadsheet looked like at the end of the day. There are a couple of important elements that I’d like to explain.

I’m going to use some real world numbers, but also abstract the client from this post. I hope I do a good job.

I found that there were 800+ unique jobs that took more than 1500 seconds to run, so this was a really good workload to send to the new batch server.

When comparing the performance I needed to add an additional dimension to the data – which was rows processed. I needed this further dimension, as if the jobs where not processing a similar amount of rows (for the main loop), then the compare is pointless. I decided to only compare batch jobs that processed a workload that was within 20% of each other.

The above filtering gave me a unique list of 221 jobs that processed a workload that was within 20% of the original amount.

Great, so this is a pretty good amount. I can compare the runtime of 221 distinct and unique real world batch jobs between the old system and the new system and see, on average, which was faster or slower.

I don’t want to let any cat’s out of the bag, but in the situation I was testing I saw that the replacement server was 2.7 times slower on average. Wow, there is some significant tuning to complete to get this thing singing.

There are lots of things that need further analysis and justification, so please don’t just assume that the replacement hardware that I’ve hinted to above is slow, by no means this is the case – it’s great. Perhaps just not as great as what it needs to be to replace a monster AS/400.

I’m going to continue the analysis, but the jury is out for the particular configuration that has just been tested.

alter session set global_names = FALSE;

SELECT JCPID as INNERPID, JCVERS as INNERVERS, simd || vrjd, count(1) as INNERCOUNT, Avg(86400*(JCETDTIM-JCSTDTIM)) as INNERAVERAGE, min(86400*(JCETDTIM-JCSTDTIM)) AS INNERMIN, max(86400*(JCETDTIM-JCSTDTIM)) AS INNERMAX, avg(jcpwprcd) as "ROWS PROCESSED"from svm900.f986114@youras400.com t1,ol900.f9860@youras400.com,copd900.f983051@youras400.com, svm900.f986110@youras400.com t2where trim(t1.jcpid) = trim(siobnm) and trim(t1.jcvers) = trim (vrvers) and trim(t1.jcpid) = trim (vrpid)and t1.jcjobnbr=t2.jcjobnbrand t1.jcexehost = 'YOURAS400'group by 'runube JDE JDE PY900 *ALL ' || JCPID || ' ' || JCVERS || CASE WHEN jcjobque IS NULL THEN N'QBATCH' WHEN jcjobque = ' ' THEN N'QBATCH' ELSE jcjobque END || ' Batch Hold Save', t1.jcpid, JCVERS, simd || vrjd having Avg(86400*(JCETDTIM-JCSTDTIM)) > 15 and Avg(86400*(JCETDTIM-JCSTDTIM)) < 15000;

The above SQL will give you a list of jobs that took longer than 150 seconds to process on the AS/400.

SELECT JCPID as INNERPID, JCVERS as INNERVERS, simd || vrjd,

count(1) as INNERCOUNT,

Avg(86400*(JCETDTIM-JCSTDTIM)) as INNERAVERAGE,

min(86400*(JCETDTIM-JCSTDTIM)) AS INNERMIN,

max(86400*(JCETDTIM-JCSTDTIM)) AS INNERMAX, avg(jcpwprcd) as "ROWS PROCESSED"

from svm900.f986114,ol900.f9860@jdeprod_dblink, py900.f983051

where trim(jcpid) = trim(siobnm) and trim(jcvers) = trim (vrvers) and trim(jcpid) = trim (vrpid)

and JCETDTIM < TO_DATE('25082016','DDMMYYYY') and JCETDTIM > TO_DATE('01062015', 'DDMMYYYY')

group by jcpid, JCVERS, simd || vrjd ;

Above is to get the results of all batch jobs processed on the linux server for compare.

Above is a graphical compare of the old and the new. The old server runtime is in blue.

Hmm, more tuning needed