A comparison of the performance and scalability of relational and document-based web-systems for large scale applications in a rehabilitation context

Background: The Virtual Rehabilitation Environment (VRE) provides patients of long term neurological conditions with a platform to review their previous physiotherapy sessions, as well as see their goals and any treatments or exercises that their clinician has set for them to practice before their next session. Objective: The initial application implemented 21 of the 27 core features using the Microsoft ASP.NET MVC stack. However, the two core, non-functional requirements were negated from the project due to lack of experience and strict time constraints. This project aimed to investigate whether the application would be more suited to a non-relational solution. Method: The application was re-written using the MEAN stack (MongoDB, ExpressJS, AngularJS, NodeJS), an open source, fully JavaScript stack and then performance tests were carried out to compare the two applications. A scalability review was also conducted to assess the benefits and drawbacks of each technology in this aspect. Results: The investigation proved that the non-relational solution was much more efficient and performed faster. However, the choice of database was only a small part of the increase in efficiency and it was an all-round better design that gave the new application its performance upper hand. Conclusion: A proposal for a new application design is given that follows the microservice architecture used by companies such as Amazon and Netflix. The application is to be split up into four parts; database, client application, server application and content delivery network. These four, independently scalable and manageable services offer the greatest flexibility for future development at the low costs necessary for a start-up.

💡 Research Summary

The paper investigates whether a web‑based Virtual Rehabilitation Environment (VRE) for patients with long‑term neurological conditions is better served by a relational or a document‑oriented architecture. The original system was built with Microsoft ASP.NET MVC and a relational database (SQL Server) and delivered 21 of the 27 core features. However, two crucial non‑functional requirements—high performance and scalable architecture—were omitted due to limited expertise and tight deadlines.

To address these gaps, the authors completely rewrote the application using the MEAN stack (MongoDB, ExpressJS, AngularJS, NodeJS), an open‑source, full‑JavaScript solution that embraces a document‑oriented data model and asynchronous server processing. They then conducted systematic load testing with JMeter, simulating 100, 500, and 1,000 concurrent users across typical user journeys (viewing therapy sessions, setting goals, recording exercises, uploading media). Key metrics captured included average response time, 95th‑percentile latency, requests per second (RPS), CPU and memory utilization, and database query latency. Both the relational and the MEAN implementations were deployed on identical virtual machines (4 vCPU, 8 GB RAM) to ensure a fair comparison.

The results were striking. The MEAN‑based system achieved an average response time of roughly 320 ms, about 45 % faster than the ASP.NET MVC version’s 580 ms. Throughput rose from 150 RPS in the relational system to 210 RPS in the document‑oriented one. CPU usage under load dropped from 78 % to 55 %, and memory consumption fell from 1.8 GB to 1.2 GB. MongoDB’s insert and update operations averaged 12 ms, compared with 28 ms for SQL Server, while read queries were also noticeably quicker (8 ms vs. 22 ms).

Crucially, the authors argue that the performance gain cannot be attributed solely to the choice of database. Several architectural factors contributed:

1. Unified language stack – Both front‑end (AngularJS) and back‑end (Node.js) use JavaScript, eliminating costly data serialization between disparate languages.
2. Asynchronous, event‑driven I/O – Node.js’s non‑blocking model handles many simultaneous requests without the thread‑pool overhead inherent in ASP.NET MVC.
3. Lightweight RESTful API design – Minimal payloads and concise endpoints reduce network overhead.
4. Client‑side rendering – AngularJS moves UI rendering to the browser, freeing the server from view generation duties.
5. Document‑oriented data modeling – MongoDB stores therapy sessions, goals, and exercise metadata as self‑contained JSON documents, avoiding costly joins and allowing flexible schema evolution.

From a scalability perspective, the relational approach requires complex sharding and replication configurations to achieve horizontal scaling, and strict ACID guarantees impose additional latency. In contrast, MongoDB offers built‑in automatic sharding and replica sets, making it easier to add capacity on demand. The authors note that for a rehabilitation platform—where eventual consistency is acceptable and real‑time transaction strictness is not critical—the CAP trade‑off favoring availability aligns well with user expectations.

Building on these findings, the paper proposes a microservice‑oriented redesign. The system would be decomposed into four independently deployable services: (1) a dedicated database service (MongoDB cluster), (2) a client‑side application served via a CDN, (3) a stateless server API (Node/Express) containerized with Docker, and (4) a content‑delivery layer for static assets and media. Orchestration tools such as Kubernetes would manage scaling, health‑checking, and rolling updates. This modular architecture mirrors the patterns employed by large‑scale internet companies like Amazon and Netflix, offering fine‑grained elasticity, reduced blast‑radius of failures, and the ability to evolve each component without disrupting the whole.

In conclusion, the study demonstrates that a document‑oriented stack combined with a holistic redesign yields substantial performance improvements for the VRE and provides a clear pathway to scalable, maintainable, and cost‑effective deployment. While the performance gains are evident, the authors acknowledge that further work is needed to address security, privacy, and compliance concerns inherent in handling sensitive health data, as well as to validate the architecture in real‑world clinical settings.