E-learning research identifies infrastructure, policy, technical capacity, learner access, and implementation support as recurring factors that influence online learning delivery [6]-[9]. These issues are relevant to online examination systems because reliability depends on both the application and the infrastructure that supports high-concurrency access. Online formative assessment literature also emphasizes that assessment quality depends on dependable online environments, timely feedback, interaction, and continuity of access [1].

Moodle was introduced as an open-source course management system designed around learning communities [4]. It has since become a widely used LMS for course delivery and assessment workflows. Official Moodle documentation and administrator guidance emphasize that production deployments require careful attention to web server configuration, database performance, caching, file storage, cron processing, and monitoring [5][24]. These concerns align with the present study because autoscaling Moodle application pods may not solve every bottleneck if the database, storage, ingress, or cache layer becomes saturated.

From a performance-engineering perspective, examination workloads should be evaluated as workload-specific scenarios rather than as generic web traffic. Computer systems performance analysis emphasizes the need to define workload, metrics, measurement procedure, and interpretation criteria before drawing conclusions [25][26]. For this reason, the present study evaluates average response time, p95 latency, p99 latency, throughput, and error rate together. This helps avoid the misleading conclusion that a system is performing well merely because the requests that did succeed were fast.

Kubernetes emerged from experience with large-scale container and cluster management systems and is now widely used for deploying and managing containerized workloads [10][11][27][28]. A Kubernetes deployment can run multiple replicas of an application pod and expose them through services and ingress components. This architecture makes horizontal scaling practical for stateless or mostly stateless application tiers, including the web/PHP tier of a Moodle deployment when shared storage, database, and session handling are configured appropriately.

Autoscaling decisions are only as effective as the metrics and thresholds that guide them. Kubernetes HPA adjusts the number of pod replicas based on observed resource metrics or supported custom metrics [12][13]. This approach can be stable because it responds to measured utilization, but it can lag sudden demand spikes if CPU or memory pressure appears after queues have already formed. Research surveys on cloud elasticity and autoscaling similarly show that reactive scaling is useful but sensitive to metric choice, thresholds, cooldown behavior, and provisioning delay [18]-[23].

KEDA is a Kubernetes-based event-driven autoscaler that scales workloads using event sources and external metrics [14][15]. In contrast to basic resource-driven autoscaling, KEDA can connect scaling decisions to signals such as queue length, message backlog, Prometheus metrics, and other supported scaler sources [14]. For an examination workload, this is attractive because demand signals may appear before CPU utilization fully reflects the incoming pressure.

However, event-driven scaling still depends on trigger configuration, polling behavior, cooldown periods, pod readiness, image pull time, and downstream service capacity. In a Moodle examination environment, bottlenecks may include PHP workers, database connections, shared files, cache services, ingress configuration, network throughput, and the load generator itself. These factors make empirical evaluation necessary before adopting KEDA for high-stakes assessment workloads [14][15][20][24].

Scheduled assessment platforms experience concentrated demand because access is controlled by examination timetables and deadlines. The relevant engineering question is therefore not whether the application works under normal use, but how it behaves when many users perform similar actions within a short window. Public-facing examination services and institutional assessment platforms can both experience this pattern, even though their application workflows differ [29].

For high-stakes examinations, error rate is a direct reliability indicator because failed requests may prevent login, page access, answer saving, or final submission. Tail latency is also important because the slowest successful requests often represent the user experience of candidates at the edge of acceptable service. The present study therefore treats latency, throughput, and error rate as complementary indicators rather than competing measures.

The study used a controlled experimental design. The independent variable was the scaling strategy: static scaling, Kubernetes HPA, and KEDA. The dependent variables were average response time, p95 latency, p99 latency, throughput, and error rate. The purpose was not to introduce new Moodle functionality, but to evaluate how the same Moodle examination workload behaved under each scaling configuration.

The comparison used identical workload levels and the same measurement definitions across all strategies. This design supports direct comparison because changes in latency, throughput, and error rate can be interpreted against the scaling strategy rather than against different workloads or application features. Each workload level was executed four times for each scaling strategy. Reported values represent arithmetic means across repeated trials. The purpose of repetition was to reduce the impact of transient system variability and improve reliability of measurements.

The experiments were conducted on an on premises k3s Kubernetes cluster deployed on HPE Synergy 660 Gen10 infrastructure. The cluster consisted of one master node (16 CPU cores, 32 GB RAM), two worker nodes (each 4 CPU cores and 8 GB RAM), and a dedicated NFS storage server (4 CPU cores, 8 GB RAM). Moodle 5.2 LMS was deployed as a containerized application running on k3s version 1.34.5+k3s1, with MySQL 8.3 used as the backend database. Moodle application data were stored on a shared NFS-backed persistent volume. Prometheus and Grafana were used for monitoring, while Apache JMeter generated examination workloads which is commonly used for load, performance, and functional testing of web applications [30]. Moodle pods were distributed across worker nodes using Kubernetes topology-spread constraints.

The static condition used two Moodle application pods and did not automatically add capacity when demand increased. This represents a common fixed-capacity deployment model in which administrators provision resources before an examination and rely on that capacity throughout the test window.

The HPA configuration used Kubernetes autoscaling/v2. Moodle pods were configured with resource requests of 250m CPU and 512 MiB memory and resource limits of 1000m CPU and 1024 MiB memory. HPA was configured with a minimum replica count of 2 and a maximum replica count of 25. Scaling decisions were based on both CPU and memory utilization with target utilization thresholds of 50% for each metric. Stabilization and scaling policies were configured to prevent rapid oscillation of replica counts during workload fluctuations. KEDA was implemented using an HTTPScaledObject. Scaling decisions were based on HTTP request rate, with a target value of five requests per second, a granularity interval of 1 s, and a measurement window of 1 minute. The configuration used a scale-down period of 180 s, a minimum replica count of 0, and a maximum replica count of 25 replicas. Readiness and startup probes were inherited from the Moodle deployment and were used to ensure traffic was directed only to healthy pods.

Apache JMeter was used to emulate concurrent Moodle users. In this study, “concurrent connections” refers to the number of simultaneous JMeter virtual users (threads) executing Moodle examination transactions. The workload model represented a typical student examination journey consisting of four phases: (i) login and dashboard access, (ii) quiz start, (iii) question interaction and answer saving, and (iv) final submission. Workload levels were configured at 500, 1000, 2500, 5000, 10,000, 20,000, 30,000, 40,000, 50,000, 60,000, and 70,000 concurrent users. Ramp-up periods varied from 5 s for 500 users to 360 s for 70,000 users. Each workload level was executed four times under identical conditions, and the reported values represent the mean across repeated trials. The same HTTP connection reuse settings, request mix, and workload profile were applied to all scaling strategies to preserve comparability.

Average response time, p95 latency, and p99 latency were calculated using successful requests reported by Apache JMeter. Error rate was computed as the percentage of failed or timed-out requests relative to total requests (Table 1). Failed requests included HTTP errors and timeout events recorded by the load-testing framework. Consequently, latency metrics should be interpreted as the performance of successful requests, while reliability is captured separately through the error-rate metric.

To support reproducibility of the results, all the deployment manifests, autoscaler configurations, workload definitions, resource requests and limits, and test parameters are provided below.

Table 1.Experimental variables, units, and measurement focus.

Kubernetes HPA deployment

root@master1:~/moodle# more moodle-hpa.yaml

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata:

name: moodle-hpa

namespace: moodle

spec:

scaleTargetRef:

apiVersion: apps/v1

kind: Deployment

name: moodle

minReplicas: 2

maxReplicas: 25

metrics:

- type: Resource

resource:

name: cpu

target:

type: Utilization

averageUtilization: 50

- type: Resource

resource:

name: memory

target:

type: Utilization

averageUtilization: 50

root@master1:~/moodle#

root@master1:~/moodle#

KEDA deployment

root@master1:~/moodle# more moodle-keda.yaml

apiVersion: http.keda.sh/v1alpha1

kind: HTTPScaledObject

metadata:

name: moodle-http-scaledobject

namespace: moodle

spec:

hosts:

- mydomain.domain.com

scaleTargetRef:

apiVersion: apps/v1

kind: Deployment

name: moodle

service: moodle

port: 80

replicas:

min: 0

max: 25

scalingMetric:

requestRate:

targetValue: 5

granularity: 1s

window: 1m

scaledownPeriod: 180

root@master1:~/moodle#

JMeter Workload timing

Table 2.JMeter workload timings.

At 500 concurrent connections, all strategies were relatively close: static scaling recorded 328 ms, HPA 283 ms, and KEDA 389 ms (Table 3). The first major separation occurred at 1000 concurrent connections, where static scaling rose to 5419 ms while HPA and KEDA remained at 253 ms and 347 ms, respectively. Static scaling then reached 10,347 ms at 2500 concurrent connections, showing that fixed capacity began to queue requests early in the workload curve.

Table 3.Average response time by workload (ms).

HPA maintained low average response time through 5000 concurrent connections, reaching 275 ms at that point, but rose to 2476 ms at 10,000 concurrent connections. KEDA recorded 252 ms at 5000 concurrent connections, 412 ms at 10,000 concurrent connections, and 1604 ms at 70,000 concurrent connections (Figure 1). These values show that KEDA delivered the fastest average response time among successful requests under several high-load conditions. However, this must be read together with the error-rate results because a fast average response time is not sufficient if many requests fail.

The p95 and p99 results show the slower end of successful request performance (Figure 2 & Figure 3). Static scaling deteriorated immediately after the first workload increase: p95 latency rose from 741 ms at 500 concurrent connections to 10,689 ms at 1000 concurrent connections and 16,803 ms at 2500 concurrent connections. It remained above 10,000 ms across most of the upper range, demonstrating persistent tail-latency instability.

Figure 1. Average response time for static scaling, HPA, and KEDA across workloads.

Figure 2. 95th percentile latency across workloads.

Figure 3. 99th percentile latency across workloads.

HPA performed strongly at lower workloads but increased sharply at higher loads. At 10,000 concurrent connections, HPA reached 7987 ms on p95 and 10,005 ms on p99, whereas KEDA recorded 939 ms and 1287 ms, respectively (Table 4 & Table 5). From 20,000 to 70,000 concurrent connections, KEDA kept successful tail requests faster than HPA. Nevertheless, the lower KEDA tail latency should not be interpreted alone because its error rate was substantially higher than HPA’s at the same high-load points.

Table 4.95th percentile latency by workload (ms).

Table 5.99th percentile latency by workload (ms).

Throughput increased for all three strategies as the workload increased, but autoscaling strategies separated from static scaling early. At 1000 concurrent connections, static scaling reached 41.99 req/s, compared with 65.21 req/s for HPA and 64.27 req/s for KEDA (Table 6). At larger workloads, KEDA recorded the highest throughput at most points, including 323.17 req/s at 10,000 concurrent connections, 756.46 req/s at 40,000 concurrent connections, and 777.74 req/s at 60,000 concurrent connections (Figure 4).

Table 6.Throughput by workload (req/s).

Figure 4. Throughput for static scaling, HPA, and KEDA across workloads.

Throughput must be interpreted with error rate because a system can appear to process many requests per second while still failing a large proportion of total attempts. For example, KEDA produced the highest throughput at 10,000 concurrent connections, but its error rate at the same point was 93.725%. This means that its throughput advantage reflected the rate of completed requests among a workload in which many requests failed.

Error rate is the most important metric for examination continuity because failed requests can prevent candidates from logging in, loading pages, saving answers, or submitting work (Figure 5). Static scaling recorded 0% error at 500 concurrent connections, 13.775% at 1000 concurrent connections, 81% at 2500 concurrent connections, and 92% at 5000 concurrent connections. From 10,000 to 70,000 concurrent connections, its error rate remained between 97.95% and 99.7%, making it unsuitable for the upper workload range (Table 7).

Across the four experimental trials, HPA consistently produced lower observed error rates than KEDA and static scaling under the tested workload conditions. It maintained 0% error from 500 through 5000 concurrent connections. At 10,000 concurrent connections, HPA’s error rate increased to 61.675%, which is severe, but it was still lower than KEDA’s 93.725% and static scaling’s 98.4%. HPA remained the lowest-error strategy at every larger workload. KEDA performed well at the beginning of the curve, but its error rate rose to 14.5% at 2500 concurrent connections, 29.575% at 5000 concurrent connections, and 93.725% at 10,000 concurrent connections.

Table 7.Error rate by workload (%).

Figure 5. Error rate for static scaling, HPA, and KEDA across workloads.

A sample interpretation illustrates the trade-off. At 10,000 concurrent connections, KEDA had a much lower average response time than HPA, 412 ms compared with 2476 ms. If response time alone were considered, KEDA would appear superior. However, KEDA failed 93.725% of requests at that workload, while HPA failed 61.675%. Therefore, HPA served a larger share of the workload successfully, even though the successful HPA requests were slower. In an examination setting, that distinction is critical because a slower successful submission is preferable to a fast failure.