# Scaling Findmypast for 1921 Census release - Part 2

DevFeed: [Scaling Findmypast for 1921 Census release - Part 2](<https://devfeed.tech/articles/scaling-findmypast-for-1921-census-release-part-2-19747.md>)

Original publisher: [Read original article](<https://tech.findmypast.com/scaling-fmp-part-2/>)

Author: Mike Thomas

Published: 2022-03-02T00:00:00Z

Content type: article

Language: en

Sources: [Findmypast](<https://devfeed.tech/sources/findmypast.md>)

Topics: [systems](<https://devfeed.tech/topics/systems.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [GraphQL](<https://devfeed.tech/topics/graphql.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Deployment](<https://devfeed.tech/topics/deployment.md>)

Tags: [automated](<https://devfeed.tech/tags/automated.md>), [chaos](<https://devfeed.tech/tags/chaos.md>), [engineering](<https://devfeed.tech/tags/engineering.md>), [findmypast](<https://devfeed.tech/tags/findmypast.md>), [graphql](<https://devfeed.tech/tags/graphql.md>), [infrastructure](<https://devfeed.tech/tags/infrastructure.md>), [k8s](<https://devfeed.tech/tags/k8s.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [load](<https://devfeed.tech/tags/load.md>), [performance](<https://devfeed.tech/tags/performance.md>), [stress](<https://devfeed.tech/tags/stress.md>), [testing](<https://devfeed.tech/tags/testing.md>)

## AI overview

Findmypast describes the second phase of scaling its service for the 1921 Census of England and Wales release. The engineering teams ran coordinated load-test game days against production, targeting up to four times normal January load. The first test day kept the site generally responsive but exposed failures in a GraphQL service and other performance and Kubernetes configuration issues.

## Source excerpt

Findmypast (FMP) released the 1921 Census of England & Wales at midnight on Jan 6th 2022 to an eager community of genealogists. The preparation of the census - preservation, digitisation and transcription took three years of hard work. Aside from the data preparation, we also had technical challenges to address. Specifically, could our services deal with the projected increase in users for the first few days of 1921 launch period? This post is the second in a series that details how we approached scaling our service to deal with a projected day one 12x increase of users. If you haven't already, I'd suggest you read the first post which details the initial scaling steps taken by our engineering teams. Stress testing "game" days We ended the first post detailing that the load tests created by the teams were effective at testing the service in isolation. The next step was to get all the teams together and run their load tests at the same time against our production service. While still not a realistic example of a user journey, it would still test how our systems as a whole responded to the increased load. Game day # 1 Initially, we set a simple schedule of a load test "game day" each month. Scheduled for Thursday 8th April and spread over two hours we planned to run 3 load tests. Each was 20 mins in duration and we aimed for the first test to add 2x our normal load, the next test was 3x and the final test was 4x the load. Note that "normal load" means the load we would normally expect in a typical January. (1921 Census was launched in January). We have seasonal visitor patterns with more visitors during (the northern hemisphere) winter months than summer. When we set our targets for the load test, we aimed for 4x the normal January load, not the current April load. Overall, the first stress test game day was a success - the site stayed alive and generally responsive. But we did learn a few things from the first day: One of our key services that deals with GraphQL quer