Following up on Nitro Boost Project Stage 1, stages 2 and 3 are now live! This had made Lifeboat one of the fastest e-commerce solutions available today!
Disclaimer
This post will be a relatively technical one, but we'll try our best to oversimplify the changes.
TL;DR
We did a bunch of cool tech things to give you and your customers a much better experience when using Lifeboat. These changes made Lifeboat one of the fastest e-commerce platforms worldwide.
The results...
| Metric | Pre-Nitro Boost | Post-Nitro Boost Stage 1 | Post-Nitro Boost Stages 2 & 3 |
|---|---|---|---|
| TTFB Server Response Time |
±0.7s | ±0.6s | ±0.4ms |
| DOM Loaded Browser Loaded the HTML |
±1.3s | ±1.2s | ±0.7s |
| Full Site Loaded Site is usable |
±1.5s | ±1.3s | ±0.9s |
| Blocking Time Time browser has to wait between loading of resources |
±0.2s | 0s | 0s |
Note: Tests are performed within the EU, if accessing sites from outside the EU timings might vary.
So how did we do it?
Decoupling Systems
One of the major bottlenecks in Lifeboat was that the internal systems were tightly coupled, the databases, web servers, and everything in between resided in tightly connected clusters. This made it easy for us to launch the MVP of Lifeboat but prevented us from properly scaling out. Cue in Amazon Web Services. Our databases now live in a "serverless" environment that can quickly scale to meet traffic demands. As from our testing any Lifeboat site can now easily handle hundreds of thousands of concurrent users.
The database was not the only issue though, the web servers also need to speak what we internally call "the morphing language", which in its most basic form means; any server in our cluster could respond to a request irrelevant to the store domain. Because under the hood we use a framework "Silverstripe" this wasn't the easiest of challenges (far from it). However, after a bit of tweaking with how configurations are loaded, and how content was rendered we managed to configure this "morphing" system. To simplify; if a Lifeboat store gets a spike in traffic, other servers can quickly come pitch in to help spread the load and offer a consistent experience.
But what does it mean for the average merchant?
Think of it this way, where we previously reserved a chunk of capacity per site leaving us with a lot of wasted resources, we now have a dynamically expandable pool of resources. If a site gets a sudden spike in traffic this pool automatically configures itself to bring more machines online to handle this load. This gives your end customers a stable and performant experience irrelevant of how many users are online.
Load Balancing
To be able to effectively distribute traffic, we also had to deploy a new system to balance the load. Cue in HAProxy. Without going into too much detail (for security reasons), this new system can handle hundreds of millions of requests, and like a traffic light system, it directs customers to the webserver best equipped to serve the request at that time. This new system also means we can now offer much more protection against DDOS, and malicious bots.
Data Structures
Finally, the last piece of the puzzle was changing how he store and retrieve data to extract as much performance from the new available systems. For obvious reasons, we can't go into detail on how this is done however, we can share that by optimising our storage systems, and data structures we managed to reduce the amount of data queried by ±70%!
Conclusion
The topics in this article are a bit tricky to explain however, the results are simple to explain. Thanks to the dedication of the dev team, Lifeboat merchants and customers can enjoy an improved experience when using Lifeboat.
