Running large-scale online exams means many users may log in at different times. However, the server must support concurrent user logins (users active simultaneously) without performance degradation. This guide explains how Addmen’s system handles concurrency, what “concurrent load” means, and its implications for server infrastructure.
In an exam that’s open over multiple days (for example, 3 days), candidates log in at different times and take the test according to the allowed duration. Not all users will be logged in continuously; many will log off when their test completes, freeing capacity. The concurrent load is the number of users actively logged in and taking the exam at a given instant.
For instance:
Suppose 10,000 candidates will take the test over 3 days.
The test duration is fixed (say, 2 hours).
Logins and logoffs are spread uniformly over time.
At any given moment, you might see 50–60 concurrent users.
So, when planning infrastructure, you size for peak concurrent users, not total registered users.
Each active user session consumes database, memory, CPU, and network resources.
The system must manage multiple parallel database connections or instances to serve these sessions.
Operating systems and DBMS may have RAM / connection limits per process or per instance which cap the number of concurrent sessions that can run smoothly.
To scale beyond those caps, you need better hardware (more RAM, CPUs), clustering, or load balancing.
A server capable of handling 50 concurrent logins is sufficient to support an exam with 10,000 candidates, if the login activity is well distributed over time.
Server Hardware & Infrastructure — Adequate RAM, CPU, disk I/O, network capacity.
Database / DBMS Configuration — Ability to support many simultaneous connections, proper caching, query optimization.
OS & Process Limits — Some operating systems and database systems limit maximum RAM usage or number of connections per instance.
Load Distribution / Clustering — In high concurrency scenarios, distributing load across multiple servers or using clustering helps sustain performance.
Monitoring & Scaling Strategy — Continuous monitoring to spot peaks; ability to scale up resources dynamically if needed.
Test active period: 3 days
Total participants: 10,000
Test duration per participant: fixed (e.g. 2 hours)
Peak active sessions at any moment: ~50–60
In this scenario, your infrastructure must be capable to handle ~60 simultaneous sessions. If the server is configured to support that many object requests, it can accommodate the entire cohort by managing user sessions over time.
Addmen Group Copyright 2025. All Rights Reserved.
