< back
~ / writing / scaling-performance-with-drupal-on-a-budget

Scaling Performance with Drupal on a Budget

This post documents migrating a Drupal application to cloud hosting under real budget and time constraints. The application had outgrown its existing platform and needed to be rebuilt with minimal infrastructure overhead.

Options Evaluated

PaaS providers (Acquia, Pantheon, Platform.sh) were the obvious starting point for Drupal hosting, but the application's requirements exceeded the limits of their standard tiers.

Dedicated servers and VPS were ruled out — the labor cost of managing the OS, database, and stack wasn't justifiable for this project.

AWS was the first cloud platform attempted. The plan was RDS for the database, S3 for file storage, and Elastic Beanstalk for the application. After roughly 8 hours of troubleshooting persistent connectivity issues between the application and the database — including multiple complete rebuilds — the setup was still unstable. AWS's configuration surface area and deployment complexity made it the wrong tool for the timeline.

Azure was the final choice.

Azure Architecture

Three services covered everything:

  • Azure App Service — Basic B2 plan (2 cores, 3.5 GB RAM)
  • Azure Database for MySQL — managed database with no OS overhead
  • Azure Redis Cache — Basic C0 tier (250 MB shared instance) for page and query caching

GitHub integration enabled automatic deployments on push, which removed the manual deployment step entirely.

Getting Redis Working

The phpredis extension isn't pre-installed on Azure App Service. Getting it working required:

  1. Download the VC14 NTS build from PECL
  2. Create ext and ini directories in the application root
  3. Add an extensions.ini file pointing to the DLL:
extension=php_redis.dll
  1. Set the PHP_INI_SCAN_DIR application setting in the Azure portal to point to the ini directory

Once loaded, Drupal's Redis module picked it up without further configuration.

Performance Notes

Switching from ClearDB (a third-party MySQL service) to Azure Database for MySQL made a noticeable difference on views with multiple joins. The improvement was largely attributed to reduced connection latency — when the database and application are in the same region on the same platform, connection overhead is minimal.

PHP configuration tuning was handled through a .user.ini file in the application root, which allows per-app overrides without touching the global php.ini.

Outcome

The full migration took about 8 hours of actual work. Performance matched the existing infrastructure, the deployment workflow was simpler, and the monthly cost fit within budget. For Drupal on a timeline, Azure was the right call.