Analysis of Optimization Techniques to Improve User Response Time of Web Applications and Their Implementation for MOODLE

Analysis of seven optimization techniques grouped under three categories (hardware, back-end, and front-end) is done to study the reduction in average user response time for Modular Object Oriented Dynamic Learning Environment (Moodle), a Learning Management System which is scripted in PHP5, runs on Apache web server and utilizes MySQL database software. Before the implementation of these techniques, performance analysis of Moodle is performed for varying number of concurrent users. The results obtained for each optimization technique are then reported in a tabular format. The maximum reduction in end user response time was achieved for hardware optimization which requires Moodle server and database to be installed on solid state disk.

💡 Research Summary

The paper investigates seven optimization techniques aimed at reducing the end‑user response time of the Moodle Learning Management System (LMS). Moodle 2.5, running on a LAMP stack (Linux, Apache, MySQL, PHP) under Ubuntu 12.10, was subjected to load testing with Apache JMeter 2.9 using a chat‑centric user scenario (login, view course, open chat, post messages). Initial measurements on a machine equipped with an Intel i5‑2310 CPU, 8 GB HDD, and 1 GB RAM showed that response times grew sharply as concurrent users increased, reaching 364 seconds at 50 users and causing a database overload at 51 users.

Hardware Optimization (SSD)
Replacing the HDD with a 128 GB SSD while keeping the RAM at 1 GB dramatically lowered response times: from 3.67 s (10 users) to 0.35 s, and from 364 s (50 users) to 5.27 s. The reduction percentages ranged from 87 % to 98 %, and the system could sustain up to 151 concurrent users before overload, compared with only 50 on the HDD. This demonstrates that disk I/O latency is a primary bottleneck for Moodle under the tested configuration.

Back‑End Optimization (LNMP)
The web server was switched from Apache to Nginx, forming an LNMP stack (Linux, Nginx, MySQL, PHP). Using Apache Benchmark on the same SSD‑based hardware (now with 4 GB RAM), the average response time decreased by 24 %–34 % across loads from 50 to 250 users (e.g., 2.21 s → 1.65 s at 50 users, 10.73 s → 7.16 s at 250 users). Nginx’s event‑driven, asynchronous architecture reduces per‑connection overhead, making it more scalable under heavy concurrency.

Front‑End Optimizations

1. Far‑Future Expires Header – By adding Expires and Cache‑Control directives that set a 10‑year max‑age for static assets, the response time fell by roughly 70 %–80 % (e.g., 0.625 s → 0.144 s at 10 users). Caching eliminates repeated HTTP requests for unchanged resources.

2. DNS Cache Tuning – Experiments across 13 universities on six continents compared response times with and without DNS caching. Depending on geographic location, caching reduced latency by 16 %–51 %. Further tests varying DNS cache entries (20 vs. 512), expiration periods (60 s vs. 3600 s), and HTTP keep‑alive settings showed the lowest response times when cache entries and TTL were increased and keep‑alive remained enabled.

3. Gzip Compression – Enabling gzip for HTML, CSS, JavaScript, and image files reduced the transmitted size of typical Moodle pages by 75 %–77 % (e.g., index page from 926 KB to 215 KB). Smaller payloads directly translate into faster network transfer and lower perceived latency.

4. ETag Deactivation – Disabling ETag headers cut the size of response headers by an average of 1,737 bytes per page. While modest, this reduction lessens TCP/IP overhead, especially on low‑bandwidth connections.

Overall Findings and Limitations
Each technique independently contributed to substantial performance gains, and when combined they transformed a modest single‑server Moodle installation into a system capable of handling three times the original concurrent load with sub‑second response times for typical interactions. However, the study is limited to a single node, low RAM (1 GB), and a fixed 1 Mbps bandwidth. It does not explore CPU utilization, memory pressure, multi‑node clustering, or cost‑benefit analysis. Moreover, the experiments were performed on relatively old software versions (PHP 5.4, Moodle 2.5), leaving open the question of applicability to newer stacks (PHP 7+, Moodle 3.x). Future work should extend the evaluation to cloud‑based deployments, horizontal scaling, and more recent technology stacks, while incorporating statistical significance testing and economic considerations.