Contact us
Load-Tested LMS for 35,000+ Concurrent Learners

35,000+

Peak concurrent users

167,500+

Transactions per hour

8

Core academic modules

Overview

Cyber Square is a coding, AI, and robotics education platform serving 500+ partner schools across India, the UAE, the UK, and Canada — with 400,000+ students taught since 2014. As adoption scaled across its Learning Management System, Cyber Square needed assurance that its exam engine, coding labs, and student dashboards could hold up under real exam-day concurrency, where thousands of students sit standard exams, lab exams, and live coding projects within the same tight windows.

Testvox designed and executed a phased performance testing engagement — built around a detailed workload model spanning every core academic transaction — to validate the platform at 50% and 100% of projected peak load, with a stress cycle beyond that to find the actual breaking point.

Challenges Faced by Client

  • Exam-day concurrency at scale With students across hundreds of schools sitting standard exams, lab exams (Python, HTML, and DB), and CS Lab project submissions in overlapping windows, the platform needed to be validated not just for steady traffic, but for the sharp, synchronized spikes that exam schedules actually produce — across the exam engine, dashboards, portfolio, scorecards, and course navigation modules.
  • A coding IDE that standard load-testing tools can't script Cyber Square's in-browser Visual Studio-style code editor (vLab IDE) runs on WebSockets to give students a real-time coding experience — keystrokes, terminal output, and live state, all over a persistent connection. Standard HTTP-based performance tools are built around discrete request-response cycles, and the always-open WebSocket connection caused scripting attempts to hang and throw socket timeout errors, threatening to block the entire engagement if not scoped correctly.

Testvox Solution

  1. Built a Transaction-Level Workload Model

    2. Testvox mapped every core student workflow — viewing and taking standard exams, viewing and starting lab exams (Python, HTML, DB), CS Lab project workflows, course navigation, portfolio views, and scorecard checks — into a detailed workload model with concurrency and transaction-volume targets validated against school-provided exam-day figures, giving both teams a shared, numbers-backed definition of "peak load."

  2. Executed Phased, Incremental Load Testing

    3. Using Apache JMeter for scripting and execution, Grafana + InfluxDB for real-time metrics, and Splunk for log correlation, Testvox ran progressive load tests at 25%, 50%, 75%, and 100% of the target workload, with defect-fix-and-retest cycles built into each stage — followed by a stress test at 2× peak load to identify the platform's actual break point.

  3. Diagnosed and Scoped Around the WebSocket Constraint

    4. Rather than let the vLab IDE's WebSocket architecture stall the engagement, Testvox's team isolated the issue precisely: the protocol conflict was specific to the IDE's real-time internal interactions (typing, live terminal updates), not the API-driven actions around it. All exam-critical, API-based actions — starting an exam, submitting code, fetching resources — were fully covered in the current phase, with the IDE's real-time layer flagged for a dedicated follow-up strategy rather than left as an untested blind spot.

Result

Exam Engine Validated for Real Exam-Day Load

Standard exams, lab exams, and CS Lab project workflows were validated up to 35,000 concurrent users and 167,500 transactions per hour — giving Cyber Square a tested baseline for its busiest exam windows, not just average-day traffic.

A Precise, Documented Technical Boundary

Instead of a vague "couldn't test everything" caveat, Cyber Square received a clear technical explanation of exactly why the vLab IDE's real-time layer sits outside standard HTTP-based load testing — and a concrete path (a dedicated WebSocket-aware strategy) to close that gap in a follow-up phase.

A Reusable Performance Baseline

The workload model, scripts, and monitoring setup built during this engagement give Cyber Square a repeatable foundation for future scalability planning, rather than a one-off test that expires the moment the platform changes.

Conclusion

By pairing a detailed, transaction-level workload model with the judgment to scope around a genuine tooling limitation rather than force it, Testvox gave Cyber Square a performance baseline built for how its platform is actually used — synchronized exam spikes, live coding labs, and all — along with a clear-eyed plan for what to test next.

Related Resources