Short answer (with my specific WordPress setup and test scenarios): 10–15 concurrent users sustainably, 100 concurrent users before WordPress crashed.
Long answer:
I recently executed a test to measure performance of a t2.micro running WordPress, as part of a training I am preparing. My test had a t2.micro running WordPress, served by Apache and with a MySQL database in the same EC2 instance. The instance was pre-loaded with 500 posts.
Each user in my test loads a random page, waits a random time between 15 and 30 seconds before moving on to the next random page.
I executed the following tests:
- 10 concurrent users
- 20 concurrent users
- 50 concurrent users
- 100 concurrent users
- 150 concurrent users
You can see the CPU utilization and memory stats for the different tests (I am running the collectd agent and collectd CloudWatch plugin inthe instance)
Right after I attempted to increase the user count from 100 to 150, WordPress crashed. It seems like MySQL couldn’t handle the load. I saw a number of database related errors in the Apache logs (“Error while sending QUERY packet.”), which resulted in HTTP 500 errors and the infamous WordPress “Error Establishing a Database Connection”. Technically, Apache didn’t crash and I’m sure there are settings I could tweak in MySQL to probably increase its performance, but I didn’t spend time doing that.
However, there is a more fundamental limitation for a t2.micro that you should be aware of, which is CPU Credits. All T2 instances are assigned a number of CPU Credits at launch, and they have a baseline CPU performance, which varies by instance type. For a t2.micro, the baseline CPU performance is 10%. If your instance CPU usage goes above 10%, it starts to deplete CPU credits. After a period of time above 10% CPU utilization, your T2 instance will run out of CPU credits and when this happens, its CPU capacity will be capped at 10% (for a t2.micro).
At 10 concurrent users, CPU Utilization was 6%. 20 users resulted in 13% CPU Utilization. This means you’ll reach or exceed 10% CPU Utilization at around 15 concurrent users. In the chart above, you can see how CPUCreditBalance goes down as CPUUsage increases.
My t2.micro could handle a spike of 100 concurrent users, but it failed at more than 100 users.
At 100 users (65% CPU Utilization), you’ll have around 54 minutes before your instance runs out of CPU Credits (assuming you started with a balance of 30 CPU Credits).
Here is a chart I prepared regarding CPU credits:
Conclusions (based on my settings and specific tests):
- In steady state, a t2.micro can sustainably handle 10-15 concurrent users. More than that and it will start to deplete its CPU Credit balance.
- 100 concurrent users was the maximum I could reach with my WordPress setup and test scenarios. At 65% CPU Utilization, a t2.micro will last around 54 minutes with this load before it runs out of CPU Credits.
If you want to know how to handle large loads sustainably (1,000 concurrent users or more), the best way to do it is by adding ELB and Auto Scaling to your setup. I wrote an article about it:
How to find an optimal EC2 configuration in 5 steps (with actual performance tests and results)
