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.