Hey everyone! I need a bit of guidance on how to determine if my current infrastructure can handle an upcoming demand. I developed an access control system for events that's starting to attract some serious attention. An important client wants to use it for events with around 10,000 access points, and we expect traffic from six different devices.
The system is built with Java for an Android app, backed by a PHP server, and uses MariaDB. Currently, I'm running a pretty complex configuration: two small Ubuntu VMs as load balancers (1 CPU, 2GB RAM) using CARP for failover, NGINX for SSL, and HAProxy for backend load balancing. Then, there are two backend server VMs (2 CPUs, 8GB RAM) running Apache with PHP and MariaDB set up for master-master replication with Galera and MaxScale.
These VMs are connected within a private VLAN across two data centers about 3 km apart due to some legal requirements for physical signature hardware.
My main questions are: how can I effectively perform a load test on this setup? I have a bit of experience with Apache JMeter; is it enough for simulating 10,000 calls from six devices on different connections? Also, are there improvements I should consider for my configuration, and what common pitfalls should I avoid when preparing for such load? Thanks for any advice and support!
2 Answers
It’s crucial to focus on how many concurrent devices your servers can handle. For your testing, consider writing a small app that sends requests and checks the responses simultaneously from multiple machines to really stress test the setup!
Using a cloud service for load testing is a solid idea! Running your tests from new VMs can help simulate real-world conditions effectively. There are also specific services that can handle load tests if you want to go that route. Definitely worth looking into!

That makes sense! My calls mainly fetch indexed records from MariaDB and do some checks. So, I guess if the index is loaded in memory and PHP has opcache enabled, it should help? I just find it tricky to estimate capacity without running tests.