"BATCH JOBS" RUNNING MORE EFFICIENTLY

One important focus of performance improvement is the scheduling and running of "batch jobs" -- running multiple amounts of data at one time. For example, calculating tuition for thousands of students is a batch job, as is packaging financial aid.

Some batch processes run during the day "in the background," but most run at night where they won't interfere with the live PeopleSoft production.

Large batch jobs, over 500 of them, run in the "batch window" from 4:30 pm to 4 am. They need to complete during that time period. If they run out of time, the data warehouse may not be refreshed for the next day. In some cases, the entire job must run before the data transfer completes.

To make sure batch jobs run efficiently, OIT staff began using Autosys, which automatically schedules and runs batch jobs one right after another. As a result, 71 batch jobs which used to take eight hours to complete, now take only five hours, recovering three hours of time to run other batches.

Future plans?
Eventually almost all 500+ PeopleSoft batch jobs will be run on Autosys. Currently, staff runs one batch job at a time. As batch jobs become more efficient and predictable, staff will run jobs concurrently, called "multi-threading."

FOLLOW UP ON ANDERSEN CONSULTING REPORT RECOMMENDATIONS

The Andersen report (http://www1.umn.edu/enterprise/docs/emails/020300-andersen_consulting_report.htm) concluded that the U's technical infrastructure was well configured and offered minimal opportunity for big performance gains, but recommended changes that would improve performance somewhat. The Performance Team will complete these changes by March 1.

The report also recommended the creation of an Advanced Application Performance Team (the Performance Team currently in place began more to explore infrastructure performance). This team will deal only with the PeopleSoft application. To date the team consists of Patrick Dierking, Team Lead; Bernie Miller; Fred Wellwood; Chris Campbell, and Todd Nielson, all staff in OIT's Application Development and Maintenance (ADM) unit.

The team is currently studying advanced performance techniques to prepare to work with one of the Andersen performance consultants who prepared the initial report. The purpose of this "mentoring" process is to develop the talent and expertise of U staff in performance improvement.

FOLLOW UP ON BIG TEN SCHOOLS/PEOPLESOFT MEETING

One outcome of the meeting was the decision to benchmark critical PeopleSoft processes to begin to determine the optimum amount of time a process SHOULD take. The four schools with the student system have benchmarked several processes for performance, volume, and transactions/hour.

Sharing this information will alert staff to performance improvements other schools have made and lead to more collaborative problem solving. PeopleSoft has not yet established its own benchmarks for student system performance.

Also as a result of the meeting, the U Performance Team is sending descriptions of performance problems and fixes to PeopleSoft Customer Connection. Patrick Dierking, Performance Team Lead, reports that he is in almost daily contact with PeopleSoft Global Support Center staff, providing details and timings.

HMMM. INTERESTING. . .

Last time we reported that the ID Change/Delete process, which used to "time out," now takes 3 to 5 minutes. In an effort to increase performance more, data base analyst Clark Johnson "traced" the path the process takes through the database.

He discovered that the process scans 1,600 PeopleSoft tables before locating the correct ID. The data base analysts have "indexed" many of these tables (just like a textbook index) to save time, but some tables still take 15 seconds to scan. The data base analysts will add indexes to those tables taking the most time.

PERFORMANCE UPDATE

Because the PeopleSoft system was "frozen" prior to the upgrade, no performance improvements have been put in production since the last Update. Several are being readied for production and we'll report on those next time. A complete list of fixes in production is at the end of this message.

IN PROGRESS

Item Due (batch)
Tuition Calc (on-line/batch)
Course Guide (on-line)
Enrollment Request (on-line)
Student Program/Plan (on-line)
Course Catalog (on-line)

NEXT UP

ISIR Load (batch)
FA Term (batch)
ISIR Correction (on-line)
Award Entry (on-line)
Customer Accounts (on-line)
Packaging (batch)
Disbursements (batch)
Checklist Summary (on-line)
Budget Maintenance (on-line)
Disburse Aid (on-line)
Late Fee Calculation (batch)
Third Party Contract (SFPTPART) (on-line)
Quick Refund (on-line)
Quick Post (on-line/batch)
Credit History (batch)
Billing (batch)
Payment Reversal (on-line)
Demographic Data (on-line)
Residency Data (on-line)
Term Activation (on-line)
Study List push button (under Enrollment Request) (on-line)
Quick Enroll (on-line/batch)
Class Cancel (online)

COMPLETE LIST OF FIXES IN PRODUCTION

PRINT TRANSCRIPTS: One transcript took 15-20 minutes to generate, now 15 seconds.
WEB ADD/DROP: Vast majority of add/drops in 7- to 10-second range, down from 20-25 seconds in Nov/Dec.
CAMPUS VISIT SUMMARY REPORT: Report routinely ran 8-10 minutes/ now about 30 seconds.
ID DELETE & CHANGE (ON-LINE): Process took 20 minutes or timed out; now takes 4 minutes. Both a student and an HR process. Will probably redesign process once worst problems are fixed.
DUPLICATE ID REPORT: Took 6 to 7 minutes, now 3.5 minutes. Both a student and an HR process.
PAYMENT APPLIER: Process ran for several hours until it ran out of hard drive space and stopped. Now completes normally.
CLASS SCHEDULE ENTRY (ON-LINE): Took 8.5 minutes. Now takes 3 seconds.
INTERACTIVE VOICE RESPONSE FOR GRADE INFORMATION (IVR): Used to take 3 minutes, now takes a few seconds.