Overview

Background

There are concerns that the EUCLID application may not perform acceptably at the start of the academic year and that later in the year it may not perform adequately for admissions.

We have had performance issues for admissions staff since Januray and have had reports that the student hub is ‘slow’. Users are concerned that these symptoms are indicators that we may hit catastrophic performance problems at the start of the year.

Over the last twelve months many changes have happened to both the EUCLID infrastructure and the EUCLID software, including database upgrade, new application infrastructure, EUCLID upgrade, roll out of new functionality and regular software patches from TRIBAL. Along with patching from Tribal, we now have a regular schedule of coporate server patching 4 times a year which is a change within the last year. 

The focus of over the last years has been to deliver new functionality and improve EUCLID while performance and monitoring have not been reviewed.

Scope

The aim of this project is to ensure we have acceptable performance for key EUCLID processes during start of term 2016.

Out of scope:

-Performance for other functions will remain beyond the delivery of this project. Next admission confirmation process starting in July is out of scope. Will focus on start of term processes.

Objectives/Deliverables

Objectives and deliverables are:

O1: Acceptable performance over start of term for key EUCLID processes

• D1: Report what the key process over start of term are. Prioritise them. Owner: Student Systems. 3 start of term processes have been identified:

     -Retrieve a student record and confirm attendance

     -Register online

     -Upload passport and visa document (self service)

• D2: Establish the load tests to put the system under the stress similar to the expected peak load and test the performance for each key start of term process as per priority. Owner: Dev Tech/SSP
• D3: Perform load tests and write up results and recommendations,as per process priority. Owner: Dev Tech/SSP

• D4: Implement quick wins from recommendations- Owner tbc

O2: Ensure the University of Edinburgh runs EUCLID based on TRIBAL's recommendations

• D5: Implement recommendations based on TRIBAL's Tech Review/written report - Owner: IS Apps Production
• D6: implement SITS changes already recommended by Tribal- Owner SSP
• D7: Implement recommendations based on Tribal’s initial software review with a report as output- Owner: SSP
• D8: Get a further software review by Tribal after the implementation of changes identified in the initial software review, and write up results and recommendations for future improvement.Owner: SSP Note: the implementation of D8 is not in the scope of this project.  

Benefits

O1: Load tests would highlight issues for the key processes , which can then be addressed. This will give some reassurance ahead of start of term.

O2: Implement vendor's recommendations so that the student record is inline with the technical and software standards.Optimum configuration as outlined by the vendor. This also gives us the best platform to continue the investigation if we continue to experience performance problems.

Success Criteria

S1: The EUCLID infrastructure setup follows fully Tribal’s technical recommendations.

S2: The number of errors message in the log files is reduced by implementing the changes recommended from the Tribal’s initial software review.

S3: We have an established load test for the prioritised key start of term processes we can re-use for future years. Caveat: they will need to be updated following functional/upgrade changes.

S4: Key processes over start of term 2016 perform acceptable. The business will need to confirm what is acceptable as success criteria, This should be documented in the load test documents and agreed with the business. However there are limits: by implementing Tribals recommendations we position ourselves to request further help/analysis from Tribal as we are then running with their recommended set up. There is no evidence to support running their recommended set up will resolve the current performance issues.

From the load tests, we can establish the impact to key processes under load e.g. How retrieving a student record when the system is under load will perform when 1, 10 or 100 people use this concurrently. We can then manage performance expectation with users as they may not deem timings are acceptable.