There is a known issue with performance if you are running our intel based Docker image on an M1 or other ARM based system.

We will be pushing out support for M1/ARM shortly..
We have a test image out there if you want to try it - using this one should provide much better performance.
https://hub.docker.com/layers/fusionauth/fusionauth-app/1.32.1_multi/images/sha256-da71d5be2bc849ef9d4e1205508fa34994973d75798a47cab9a8484ee2592ff7?context=explore

is the latest current experimental version. Make sure you choose the arm64 based image.

You can improve the performance of FusionAuth.

Like most applications, you should load test your particular situation. Will you have a lot of registrations? User searches? Logins? Will traffic be steady state or come in waves?

FusionAuth tends to be CPU bound when it comes to logins, because that's the goal of password hashing algorithms.

In general you can scale FusionAuth two ways:

vertically. This means using a bigger server. horizontally. This means using more servers. FusionAuth is 100% stateless and can scale with as many nodes as you'd like.

Don't forget that FusionAuth isn't an island; make sure that the database FusionAuth is using is scaled appropriately, as well as Elasticsearch, if applicable.

Here are some specific numbers that may be helpful to you: https://fusionauth.io/community/forum/topic/8/what-level-of-performance-can-we-expect-with-using-fusionauth-as-an-idp

For detailed answers about your specific use cases, we recommend purchasing a support contract so that we can dig into particulars. You can do that here.

Hi!

I've made an additional investigation and found out that for some reason Fusionauth instances deployed in my k8s cluster don't utilize all CPUs available on the nodes. There are 6 nodes with 12 CPUs each, but a single Fusionauth instance hardly ever utilized even 1 CPU.

I've tried to scale horizontally, deploying 50, 60, 75 and more Fusionauth's instances and got much better result during my load testing, up to 250 logins per second (each login - two requests - /oauth2/authorize and /oauth2/token).

I wonder why this could happen and and if there are there any settings for Fusionath or Java or k8s that could help to solve the issue?

Thanks!

Thanks @sjswami , this duplicate ids issue is now resolved in 1.19.7. Appreciate you letting us know about it: https://github.com/FusionAuth/fusionauth-issues/issues/890

Ah, yes, thanks for explaining.

Yes

You have two options

use the API to integrate with the current login/reg flow with FusionAuth. This lets you keep your existing html pretty much untouched, you're just calling out to FusionAuth instead of the database. remove them and use the FusionAuth provided pages with OIDC. This lets you use the theming and localization capabilities of FusionAuth, including super simple social signon.

It's your choice based on what your needs are, either way will work.

I'd only recommend using SAML if you have an application which only supports SAML, not OIDC.

You'll also want to make sure that when someone registers with one of your applications in FusionAuth, they register with all three. I'd probably use a webhook to ensure that.

We have load tested our medium deployments to roughly 20 logins per second. It can vary quite a bit. We ship with PBKDF2 and a factor of 24,000. That configuration is the primary limiter to how many passwords we hash per second.

Tune it up to bcrypt factor 14, and it may take 3-5 second per hash. You can also tune the factor down from the default scheme to increase logins per second - it is a trade-off between security and performance.

And you can change these settings at the tenant or user levels: https://fusionauth.io/docs/v1/tech/apis/tenants
https://fusionauth.io/docs/v1/tech/apis/users