1. Use a content distribution network (CDN)
This should be a given.
Moving all your static resources to a CDN is by far the easiest way to tweak a bit more performance out of your server. Yet many of the sites we see have not done this.
Serving static files from your web server takes clock cycles, bandwidth, and threads away from what your web server should be doing – serving dynamic content.
You can even add a CDN if you are unable to change your application by using proxies like CloudFlare or CloudFront.
There is really no excuse.
2. Apply the right tool to the job
Contrary to popular belief from the past decades, the relational database is not a Swiss army knife.
Relational databases are the most common reason why the websites of our customers fail to scale. Not many developers or architects seem to realize that there are other ways to persist your data – NoSQL databases, blob storage, message queues, push notification and browser storage just to name a few.
If you want your application to scale, you will need to pick the right tools that fit your requirements. I say ‘tools’, plural, because it is not a replacement for the relational database. You will most likely end up with a set of tools and your data may be distributed and replicated between them.
I realize this sounds a bit scary. You will need to have a broad knowledge of and experience with different tools and technologies in order to pick the right ones. Your application will need to support the ones you have picked. Finally, you need to run it in a production environment.
It sounds scarier than it is. In my experience, scaling a relational database is harder.
3. Build elasticity into the application
Performance is not just about hardware, tools, and algorithms. It is also about how you chose to design and build your application.
Scaling horizontally is generally preferred over vertically. That means that you should favor adding additional smaller servers when you scale over replacing servers with larger ones.
This is vital if your application is running in the cloud. When you scale horizontally, your application may need support for e.g. easily adding new servers with bootstrapping and serving the same user from multiple servers, just to name a two aspects.
In return, you get an application that is easy and inexpensive to scale.
4. Toggle features
Despite your efforts to maximize performance, you are bound to end up in a situation where there is a shortage of resources. In this case, it is better to have a responsive, basic website than an unavailable, feature-rich one.
Build your application with Ops Toggles so that performance intensive features are disabled when resources are low. You may choose to disable advanced search and some personalized content like a “Recommended for you” ecommerce panel.
Of course, this will lead to a degraded user experience, but it is likely to be far better than a 503 Service Unavailable response.
5. Shard your resources
You may also want to partition or shard your resources. Sharding is the process of splitting up your data so it resides in different tables or often different physical databases.
Distributing data in this way means that a shortage of resources in one partition will not affect users running on other partitions.
There are several data models for accomplishing this, so you can choose a way that best matches the needs of your application.
6. Minimize Latency
Many web servers are limited by the number of concurrent threads. Having long-running requests will drain your performance.
Make sure you monitor the latency of requests and take initiatives to reduce it. High latency is usually caused by blocking code in your application like database requests, and latency is likely to increase over time as more data is accumulated and the number of concurrent requests increases. In order to reduce latency, you should use caching as much as possible, reduce locking to a minimum and maybe change the underlying tool to one with faster response time.
7. Learn to use a performance profiler
Locating a performance bottleneck is a bit like finding a needle in a haystack. Yet most developers will start looking at their code to find it.
What they should be doing is looking at data. A good performance profiler will collect data and visualize in a way that makes it easy to locate the bottleneck(s).
There is a bit of a learning curve, but that will be paid back many times as more performance issues are solved.
8. Run load tests
When we ask customers how many concurrent users their website can handle, they usually have no idea. Or, they expect to be able to handle way more than they actually can. While it is an important question to answer, it does often reveal that they do not run any kind of load testing.
In recent years it has become easy and inexpensive to run load tests with open source tools like Apache JMeter and Gatling when run in the cloud using a service like RedLine13.
Run your tests regularly with a setup and data that is as close to production as possible.
9. Know that the browser is a powerful virtual machine
Your server capacity is usually quite limited, either by physical hardware or cost. In contrast, the power of end-user browsers scales with the number of users.
By rethinking the way we build our website, our servers will be freed up to focus on data access and security, while HTML templates and some data access can be handled by cache servers and CDNs.
10. Rethink business rules
In many situations, your performance bottlenecks are complex business rules that force you to build complex code.
In other cases, it is a third-party service, such as a payment gateway, which limits performance.
In these cases, it is worth revisiting the business rules and trying to simplify them.
Do we have to pick the item from the inventory when it is added to the basket, or is it fine to do it asynchronously when the order is completed? Can we complete orders without authorizing credit cards?
Oftentimes decision-makers will change the rules once they learn about the consequences.
11. Ask: What will I gain from increased performance?
Like any project, they “Why?” should always come before the “How”.
In other words, before spending a lot of time and money on redesigning your system to handle more concurrent users, remember to consider your business.
If your business is to sell a limited stock to a large audience, like a sneaker release or popular concert tickets, there is no reason to spend resources on a system that can handle all users at once.
In such a situation, it’s fine if your site has high capacity. But if you open the flood gates and allow far more people than there are tickets, you’re setting users up for disappointment.
A better solution would be to keep excess visitors in a first-in, first-out virtual waiting room.
Designing and building a scalable website isn’t easy. The infinitely scalable website will always be out of reach.
But, if you use a combination of the right technical tools and business processes, you’ll have yourself an exemplary website.
If you’ve gone through all 11 of these essential steps, you’ll be well on your way.
Written by: Martin Larsen, Director of Product, MScIT
(This post has been updated since it was originally written in 2015.)