Identity/AttachedServices/DeploymentPlanning/TrafficModel
Overview
Herein we will construct a high-level aggregate model of how users will interact with the PICL backend services. It's an attempt to inform capacity and loadtest planning based on some real data from existing services, some educated guesswork, and some hand-waving.
Assumptions:
- ten times as many users on the new system as there are on current sync.
- roughly similar per-user behaviour as current sync (e.g. data volume, change rates).
- roughly similar per-user keysigning/authentication overheads as current persona.
- err on the side of caution; overestimate in the face of ambiguity.
Raw data and some preliminary analysis can be found in https://id.etherpad.mozilla.org/picl-user-model
Users and Devices
Due to the enormously more effective Setup/Signin UI, we should be ready to support the following very soon after launch time:
- 20 million total user accounts.
- 15 million active users hitting the service in a 24-hour period.
This is only a small fraction of the firefox userbase, but it's a lot more than current sync.
The number of devices per user is a power-law-distribution in current sync, and we anticipate the same for PICL. Erring on the side of caution:
- 90% of users have 1 device
- 8% of users have 2 devices
- 2% of users have 3 devices
- negligible number of users with > 4 devices
The split between desktop and mobile device will mirror that seen in current sync:
- 85% of devices are desktop
- 15% of devices are mobile
Account Operations
Create Account
During the changeover, we expect an influx of account setup activity as users migrate over. Let's say two weeks to get to 20 million user accounts:
- 17 create-account operations per second
This should drop somewhat after initial release, so let's plan on that as peak capacity for now.
Register Device
There are 1.12 devices-per-user, which will all have to be registered when the users account is registered. To allow for resets, upgrades, etc, that's also posit that each device needs to re-register itself once every two weeks:
- 19 register-device operations per second due to initial signup
- (20mil * 1.12) register-device operations every two weeks due to re-registration
- 37 register-device operations per second
Sign Certificate
Certificates last for 1 hour. Lets say each device is online and syncing for 12 hours each day, making 12 sign-certificate requests per device per day.
- (15mil * 1.12 * 12) sign-certificate requests per day
- 2333 sign-certificate operations per second
Change Password
Rare. Do we need to factor this in at this stage?
Detach Device
Rare. Do we need to factor this in at this stage?
Delete Account
Rare. Do we need to factor this in at this stage?
Scrypt Helper
The scrypt helper is used by mobile devices during authentication aka "device registration". At 37 register-device operations per second and 15% mobile devices, we have:
- 5.5 scrypt-helper requests per second