This post, clickbait title and all, is part of a series explaining how I managed to cut our Symfony2 application’s response time by a factor of 2 without changing anything in the application itself.
In this series:
- Part 1. MySQL vs MariaDB
- Part 2. Apache2 vs Nginx
- Part 3. The impact of the migration on performance
The infrastructure
Here is what part of the new infrastructure ended up looking like (Varnish is OFF for now):
So how does it perform in real-world use?
I mainly monitor the application with NewRelic and Graphite. Here are the metrics they picked up:
Average response time in real-world use:
| Before | After |
|---|---|
| 1sec ~ 1.3sec | 300ms ~ 400ms |
That’s response time cut in half. Not bad, right?
Conclusion
And that wraps up my field report. The application was only unavailable for 26 minutes, the time it took to migrate the database.
I know it would have been more interesting to migrate one building block at a time, finishing with the hardware migration, to find out which component brought which gain, but I had a tight deadline to migrate the whole infrastructure.
I’ve only shown you the Symfony2 application, but all in all, 8 servers had to be set up and their projects migrated. And I’d like to thank #Ansible, without which I would have spent 2 times as long on the migration (hmm, I should really write up my experience with Ansible…).
In the end, this 50% gain comes down to:
- The switch to a new network and new hardware (thank you, SSDs)
- The move from Apache / MySQL to Nginx / MariaDB
Load balancing plays no part in this gain: when I tested with a single backend, response times were no different. It’s there purely for scalability.