Introduction

As part of an unusual project, our team set out to restore a Drupal site with major performance and stability issues. Although we have a team specialized in this technology, I do not. Nevertheless, we successfully met the challenge, adding this project to our long experience of recovering and improving unstable projects.

A well-known client, whose identity will remain confidential, plays a key role in parliamentary debates between various countries and governments around the world. His website, initially built by a competing agency, was performing so poorly that the client turned to our expertise to get it back on track.

Problems and solutions

I don’t have a particular affection for Drupal. I don’t master this CMS and I’m not really a fan of its code and structure. I was therefore surprised to be brought on board on this project with the Drupal team, before learning that I would have a completely different role to play. Indeed, I was able to avoid cleaning and refactoring the code, but I was given a big responsibility. In addition to the performance issues inherent to this particular Drupal, the client’s production server was going down randomly, making the site inaccessible.

At first, I assumed that these were DDoS attacks. After all, when dealing publicly with the actions of certain governments, it’s common to experience such attacks aimed at silencing the site. However, given the initial performance of Drupal (more than 5 seconds to load a page) and the specifications of the production server (2 CPUs and 256 MB of RAM), it was obvious that the site could go down without even needing an attack. Opening a single page per second was enough to bring it to its knees.

While the rest of the team worked to get the Drupal site back up and running, I was tasked with setting up a new, secure, high-performance environment.

Results

Without going into detail, due to confidentiality agreements and professional secrets (let’s just say that this article has served as a good basis for our work), we can nevertheless point out that the site now returns a page on average in just 200 milliseconds, including network time. Despite daily traffic of over 300,000 requests, the site still has sufficient resources to handle peak loads of several million requests per hour.

Today, my responsibility is still to monitor and maintain the server. I’m pleased to say that since the infrastructure was put in place, the site has had 100% availability. In addition, we are successfully blocking over 5,000 attacks daily.

Conclusion

The recovery and remediation of a Drupal site with severe performance and stability issues was successfully accomplished by our team. We were able to get the site back up and running by resolving the performance issues and establishing a secure and robust environment. These results are a testament to our commitment to excellence and our ability to always overcome challenges!