When some users of a national library’s digital newspaper collection began experiencing delays of up to 60 seconds, routine performance data showed that something was wrong—but not why.
By correlating request times, system activity reports, and runtime logs, our team traced the slowdown to the server’s swap configuration. A targeted configuration change substantially reduced swap activity and improved performance during periods of high demand.
The case demonstrates why reliable digital collection access depends on both continuous technical monitoring and experienced investigation.
The performance problem
Most requests to the collection were completed within three seconds. During busy periods, however, some users waited for up to 60 seconds for searches, pages, or other requests to finish.
The server remained available, but the variation in response times created an inconsistent experience for those using the collection. The initial performance data suggested that additional processor or memory capacity might be required, but resource usage alone did not explain why only some requests were affected.
To identify the underlying cause, the Veridian team examined several layers of system information:
- Request-time charts showing how long different types of requests took to complete
- System activity reports showing changes in server resource use over time
- Runtime logs identifying processes that had not completed as expected
This analysis allowed the team to compare application response times with activity taking place elsewhere in the hosting environment.
What the monitoring data showed
The investigation did not indicate that Veridian Software itself was failing. Instead, the performance issue arose from the configuration of the underlying server environment.
The team found that the longest delays coincided with increased SWAP activity. SWAP acts like backup memory. When the server’s main memory, or RAM, becomes full, it temporarily moves some data to storage. This helps the server continue operating, but storage is much slower than RAM, so heavy SWAP activity can reduce performance.
In this case, the server had two SWAP partitions, which are separate areas of storage set aside for this purpose:
- A slower 15GB partition.
- A faster 64GB partition.
The server was using the slower 15 GB partition before the larger, faster partition. During periods of increased demand, this configuration contributed to longer request times as the system moved data between physical memory and the slower storage device.
Related case study: University of Illinois Enhances Digital Archives with Veridian
Correcting the swap configuration
The Veridian team disabled the slower 15 GB swap partition and reconfigured the server to use the 64 GB partition on faster storage.
This targeted change enabled the server to manage temporary memory activity more efficiently without requiring an immediate increase in processor or RAM capacity.
The performance improvement
Monitoring data collected after the change showed a substantial improvement:
- Peak-period response times improved
- Concurrent process counts fell from approximately 120 to 60
- Swap activity fell from approximately 3,400 to 225 pages per second
The reduction in concurrent processes indicated that requests were completing more efficiently rather than remaining active and adding to server congestion.
The lower swap activity also showed that the system was spending considerably less time moving memory pages to and from disk-based storage.
Concurrent process counts before and after the configuration change
Move the slider to compare peak concurrent process counts, which fell from approximately 120 to 60 after the change.
Request completion times before and after the configuration change
Swap activity before and after the configuration change
Move the slider to compare swap activity, which fell from approximately 3,400 to 225 pages per second.
Why continuous monitoring matters for digital collections
Automated monitoring can reveal unusual response times, resource use, or system activity, but an alert does not always explain the underlying cause.
In this case, identifying the problem required the Veridian team to compare several forms of technical evidence and distinguish an infrastructure configuration issue from an application-capacity problem.
Without that investigation, increasing the server’s processor or RAM might have reduced some symptoms without addressing the configuration responsible for the slowdown.
For libraries, archives, and other cultural heritage organizations, this matters because collection performance affects more than technical metrics. Slow or inconsistent access can interrupt research, discourage repeat visits, and reduce confidence in an important public resource.
Continuous monitoring helps identify emerging issues before they become sustained service problems. Experienced analysis then helps determine which action is appropriate, whether that involves application behavior, infrastructure configuration, capacity planning, or another part of the hosting environment.