Under pressure: how the ePortfolio system performed during ARCP
During the summer the NHS ePortfolio experiences a significant increase in the level of usage and activity in the lead up and during the ARCP process for Foundation and Specialty trainees.
As shown in the Figure 1 below, the number of page loads due to extensive user activity peaks towards the end of May with 3.1 million page views across the entire ePortfolio. Over half of these are specifically Foundation ePortfolio users.
Of interest is the average page load times that peaks in mid-June. This is particularly marked in Foundation-specific data and can be accounted for by the change in the type of pages being accessed during June compared to May. During ARCP reviews the server will be generating a higher proportion of complex report pages that require the server to have to process more data.
Figure 1. Page views (blue lines) and average page load time (red line) for all users (a) and just Foundation Users (b)
The performance of the server (Figure 2) showed spikes in the data transfer rate (blue lines) and measured overall server response time (elapsed time, red lines) with a peak coinciding with the date of highest usage (22nd May). Greater daily spikes are seen seen during June while transfer rates flatten from the end of May onwards. The occasional transfer rate troughs coincide with scheduled downtime for software updates. Users who may have experienced delays in opening pages or submitting forms during May and June may have been subject to network issues related to local IT systems or infrastructure that we can’t detect or influence.
Figure 2. Server performance during May and June 2013: data transfer rate (blue lines) and overall server response time (red lines)
Overall, there was no reported or detected performance problems with the ePortfolio that could be attributed to high levels of general activity (as seen prior to ARCP) or by high levels of complex processing activity (as seen during ARCPs). This can for the most part be attributed to recently implemented server architecture that can be “powered up” during peak times but also to ongoing efforts by the development team to identify and remove software and data “bottle necks”.