How to perform load testing on FusionAuth for spiky traffic patterns?

[FASupportBot]

We need to include FusionAuth in our regular performance testing to handle very spiky demand patterns in our application. This is a requirement before we can scale up in production and will be an ongoing need. What guidance can you provide on how to best approach load testing FusionAuth in our test environments?

[FASupportBot]

Load testing FusionAuth typically involves using a modern tool like k6 to simulate your expected traffic patterns. Here's the general approach:

1. Use k6 or other HTTP-capable load testing tools: While k6 is a good modern option, FusionAuth can be load tested with any HTTP-capable load testing tool such as Gatling, JMeter, or Locust. FusionAuth also provides an open source load testing repository with pre-built scenarios including creating tenants and applications, registering users, logging users in via the Login API, and full Authorization Code grant flows.

2. Profile your traffic: Use your load testing tool to determine what your actual traffic patterns will look like, especially accounting for your spiky demand. This helps you understand the load FusionAuth will need to handle. Look beyond just averages—also check the p95 (95th percentile) response time to understand the experience of your slowest users.

3. Test in a production-like environment: It's critical to load test against an environment that mirrors your expected production setup. If you're using FusionAuth Cloud, the Basic Cloud tier (single node running FusionAuth, Elasticsearch, and PostgreSQL together) is not representative and not recommended for load testing. Instead, use a Business Cloud or High-Availability plan for meaningful load testing. You can spin up an HA instance, run your tests, and tear it down—you'll only be charged for the time it's running.

4. Notify FusionAuth if testing on Cloud: If you're load testing on FusionAuth Cloud, open a support ticket to let the team know when you plan to stress test, as they monitor CPU and other metrics.

5. Monitor the right components: Performance bottlenecks are typically the database or CPU nodes. Both logins and user creation are CPU-intensive due to password hashing. If testing a multi-node system behind a load balancer, disable sticky sessions as they are not required for FusionAuth.

6. IP allowlisting considerations: If you're using FusionAuth Cloud, you may need to consider IP allowlisting depending on your security configuration. FusionAuth Cloud has protections in place to prevent DoS attacks and keep services running smoothly.

The specific approach can vary based on your exact traffic patterns and requirements, but these are the key components most customers use when load testing FusionAuth.

Related Documentation

• Load Test Documentation - Comprehensive guide on load testing FusionAuth, including tool recommendations and best practices
• FusionAuth Load Tests GitHub Repository - Open source load testing scripts with pre-built scenarios
• Handling Spiky Game Traffic: Registration & Autoscaling Best Practices - Specific guidance for handling spiky traffic patterns during high-demand scenarios
• FusionAuth Cloud High Availability Architecture - Details on HA deployment options for production-like testing
• FusionAuth Cloud Security - Information about Cloud security protections and rate limiting
• Troubleshooting Performance - Guide for troubleshooting performance issues
• Scaling Your Auth - Best Practices for Performance and Security - General guidance on scaling authentication systems