Chapter 36 — Systems, endpoints and hardware security: performance and scale
Lesson map
Lesson 36 published. Map, example, EX106.
flowchart TD
N0["Learning outcomes"]
N1["36.1 Performance"]
N2["36.2 Network load"]
N3["36.3 Growth"]
N4["36.4 Bottlenecks"]
N5["36.5 Monitoring"]
N6["Measuring performance impact"]
N7["Storage growth"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX106"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["36.1 Performance"]
N2["36.2 Network load"]
N3["36.3 Growth"]
N4["36.4 Bottlenecks"]
N5["36.5 Monitoring"]
N6["Measuring performance impact"]
N7["Storage growth"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX106"]
[Learning outcomes]
|
v
[36.1 Performance]
|
v
[36.2 Network load]
|
v
[36.3 Growth]
|
v
[36.4 Bottlenecks]
|
v
[36.5 Monitoring]
|
v
[Measuring performance impact]
|
v
[Storage growth]
|
v
[Worked example] --> [Exercise EX106]
Learning outcomes
You will (1) assess performance impacts; (2) plan for growth; (3) avoid bottlenecks.
36.1 Performance
Application control adds negligible delay to program start; restore runs after hours.
Mateo measured both claims rather than assuming them. The start-time comparison below shows the delay from application control is too small for patrons to notice. Running the restore after closing means its cost in processing and disk activity falls on hours when nobody uses the PCs, so patrons never wait for it. The only daytime cost of the design is the logoff clean-up, which takes a few seconds between sessions and was timed during the pilot.
36.2 Network load
Weekly full reimages generate large traffic; they are staggered by branch.
A full image is many times larger than the patron area, so three hundred PCs reimaging at once would saturate the links, especially at Eastgate. Mateo schedules each branch in its own slot on Sunday night, with Eastgate given the longest slot because its link is slowest. Within a branch, PCs start in small groups. The load test confirms that staggered reimages finish well before Monday opening. The schedule is in the shared change calendar.
36.3 Growth
Fernhill plans 60 more PCs. Restore server capacity is checked: current peak use is 40%.
Forty per cent at peak leaves room for growth, but Mateo checks what peak means: it is the Sunday reimage, not the nightly restore, which uses the local copy and barely touches the server. Adding sixty PCs raises the reimage load in proportion, which the worked example estimates. He also checks disk space on the server for the extra image versions the new PCs will need. Both checks are repeated before the new PCs arrive.
36.4 Bottlenecks
Eastgate's link is the main bottleneck; upgrading it is recommended.
The timing measurements and the load test both point to the same link. Staggering works around it for now, but any growth at Eastgate, or a larger image after a major update, could push reimages past their slot. Mateo writes the recommendation with the evidence: slow nights, the supplier's link records and the load test result. The upgrade cost goes to the board with the next quarterly update. Until then, Eastgate's slot is watched each week.
36.5 Monitoring
Performance metrics join the dashboard.
The dashboard gains three performance figures: restore duration by branch, weekly reimage duration and server load during the reimage window. Each has a warning level set from the pilot measurements, such as the thirteen-minute restore warning. Marta sees trends over months rather than single nights, which is what capacity planning needs. Librarians' view of the dashboard does not include these figures, since they cannot act on them. Warning levels are reviewed when hardware or the image changes significantly.
Measuring performance impact
To check that security controls do not slow patrons down, Mateo measures program start times with application control off and on across 50 launches each. The difference is under a tenth of a second, which patrons will not notice. Logon time is also measured before and after hardening, showing no meaningful change.
These measurements answer a librarian's concern that security would make PCs slow.
Storage growth
Local restore copies need disk space; Mateo checks that every PC model has enough free space for two image versions.
Load testing
He simulates all branches reimaging at once to find the upper limit, then confirms staggering keeps load well below it.
Future capacity
Capacity is reviewed annually.
Reporting
Performance results go into the thesis and the board update, showing that security did not slow PCs.
Interpreting
Performance and capacity are sufficient for current and planned use.
Risks
The Eastgate link remains a risk until upgraded.
Monitoring
Server load is shown on the IT dashboard.
Patron experience
Librarians report no complaints about speed after hardening, matching the measurements. Mateo keeps the measurement scripts so they can be rerun after future changes, such as a new browser version that could affect start times.
Worked example
Mateo simulates adding 60 PCs: peak server use rises to about 48%, within capacity.
Synthetic case. Synthetic.
Errors and limits
Scaling estimates must be checked after growth.
Exercises
- EX106 — Reimage traffic. How is reimage traffic managed? Rubric: 3 = staggered by branch; 2 = partial; 1 = vague; 0 = none.
- EX107 — Capacity. What is current peak server use and after growth? Rubric: 3 = 40% → ~48%; 2 = partial; 1 = vague; 0 = none.
- EX108 — Bottleneck. What is the main bottleneck? Rubric: 3 = Eastgate link; 2 = partial; 1 = vague; 0 = none.
Synthesis
Plan capacity and remove bottlenecks before growth.
Continue studying — chapter 36 of 50
← Chapter 35 (draft) · Course chapter index · Chapter 37 (draft) →