Speed may appear as the ultimate goal for high-traffic websites.
Your app must respond fast, but not at all costs.
Are you ready for production?
If you expect high traffic (peaks) in production, your app must be prepared for it:
- multiple layers of cache (Varnish, Redis, opcache, HTTP, etc)
- optimized database queries
- optimized memory usage
- CPU monitoring
And many more...
Nothing new, but it won't be easy.
Don't bet everything on the cache layers
Cache is vital, but like any other layer, it must be configured correctly according to a specific context.
You may connect your app to a Redis server or similar technology and still get bad performance.
For example, if you store too much data, you may exhaust your infrastructure when other components need to communicate with Redis.
It's a classic paradoxical effect that happens when you put all data in cache, hoping everything will flow automagically.
However, the problem is not Redis. It's just not the right config.
If you don't add any layer between the database (e.g., Mysql) and your PHP app, you have a bigger issue, as the number of simultaneous database connections is limited, and you can't queue requests forever.
Good architecture is challenging
CPU and RAM are essential, but there are other parameters to consider for traffic peaks:
- network bandwidth
- I/O usage
- disk space
- number of database connections
You won't solve all your problems just by adding more CPU cores or memory, and these resources are particularly expensive.
Besides, all APIs, platforms, and services used in modern projects have strict rate limits.
It might seem obvious, but many organizations struggle to find the right configuration for traffic peaks.
You will likely experiment some failures.
Speed: the nasty trap
Traffic peaks require specific packages and configs.
Otherwise, you will fall into one of the most common traps for dev teams:
it works perfectly on my localhost
In other words:
it works for me
Don't dev blindly, and I'm not saying that to patronize, as this problem happened to me and many other devs:
The app responds ultra-fast to the first user but then crashes for other treatments because you just burned all of the fuel, and it's not always easy to spot before deployment, especially as a beginner.
How to fix the problem
Optimize your settings
- fine tune PHP config according to your CPU and RAM
- only add the necessary extensions, as loading them is not free
- enable opcache (opcodes cache)
- practice regular load tests (e.g., stress, spike, soak tests), not just functional tests
- define your own metrics: What is a failure? What is a success? What is an acceptable response time?
- adjust these metrics: it's unlikely you will find the perfect configuration the first time and it will evolve
- use third-party services (e.g., artillery.io or similar services)
Spend time on your architecture
Whether you have a monolith or some micro-services to maintain, modern project usually rely on various third-party APIs, databases, and other processes that increase latency and consume lots of resources.
As a developer, be extra vigilant with the following:
- database schemes
- cache invalidation
- rate-limits
- autoload
- memory usage
- timeouts
Wrap up
Traffic peaks are hard to predict, perhaps unpredictable, which requires specific devs and configs.
Increasing server capacities IS justified in some cases, but it should not be the unique answer.
Top comments (8)
We are too much focusing on performance, whereas there is so much more. It reminds me this conference of Matz the creator of Ruby. One thing made me laugh : if you want speed just write everything in C then. :')
Haha, PHP extensions are written in C.
I understand performance is critical for the success, but speed should not be the unique goal, as you want to deliver for all users, and web apps usually provide various features. It's even more frustrating for users if they can't generate invoices or send notifs, just because the resources are exhausted.
The problem is some optimizations give a false impression of performances by only focusing on speed.
Oh yeah of course, what is leading to this situation to your mind ?
Various reasons, but it may include the following:
I think the key here is also that even if increasing server capacity is the answer, if you haven't planned it in advance you're still screwed : If your database server is barely managing and you see a 10x or 100x increase in traffic, unless your database server is really ancient you won't get a new server that's 10x as fast no matter how much money you throw at it, it just doesn't exist. Of course you could buy 10 or 100 servers, but if your application is not designed to support sharding it will require a massive rewrite that you definitely don't want to do when your business is booming and your architecture is failing.
So I think the important part is to plan ahead : You don't need your architecture to support 100x the current traffic, but you need to have a plan in case it happens.
Definitely. Besides, such upgrade is usually not instantaneous.
There are various situations that can't be solved with "simple" scaling.
Instead of digging so deep trying to squeeze every little bit of performance out and implementing risky setups that may or may not improve anything.
Isn't this why we have load balancing and autoscaling?
Just spin up another couple of servers to handle peak traffic, save yourself a myriad of headaches.
"squeeze every little bit of performance out and implementing risky setups"
no.
Horizontal scaling is not incompatible with other optimizations. You may have several strategies but it cannot counterbalance bad implementation or unexpected timeouts, unfortunately.