Which UI do you use?

Custom UI

Pre built UI

Tuning Performance

If you are facing preformance issues, here are some tips to help you tune the performance of your SuperTokens setup:

• If you are self hosting the the SuperTokens core, know that it is stateless and can be scalred horizontally. You can add more instances of the core service to handle more requests (behind a load balancer).
• Check which part of the request cycle is slow. Is it the SuperTokens core responding slowly, or is it the backend SDK APIs responding slowly? The performance of the backend SDK API depends mainly on how you have setup your API layer (that integrates with our backend SDK) to perform. You can check which is slow by enabling debug logs in the backend SDK, and then inspecting the timestamps around the core requests. If they sum up to be much less than the total time taken for the request (from the frontend's point of view), then the bottleneck is likely in the backend SDK.
• If you are self hosting the SuperTokens core, check if there are any database queries that are too slow. You can do this using debugging tools provided by the PostgreSQL or MySQL databases. If you find a query that's causing issues, please reach out to us.
• Check that the compute used to run the backend SDK, the SuperTokens core (in case you are self hosting it), and the database is sufficient. Using a t3.micro EC2 instance for the core should work well for even 100,000 MAUs. You can check the CPU and memory usage of the instances to see if they are being maxed out, or if you have run out of CPU credits. If they are, you can consider upgrading the instances to more powerful ones.
• In case you are self hosting the SuperTokens core, you can tune its performance by setting different values for the following configs in the config.yaml file, or docker env:
  • max_server_pool_size: Sets the max thread pool size for incoming http server requests. Default value is 10.
  • postgresql_connection_pool_size (if using psql): Defines the connection pool size to PostgreSQL. Default value is 10.
  • postgresql_minimum_idle_connections (if using psql): Minimum number of idle connections to be kept active. If not set, minimum idle connections will be same as the connection pool size. By default, this is not set.
  • postgresql_idle_connection_timeout: (if using psql): Timeout in milliseconds for the idle connections to be closed. Default is 60000 MS.
  • mysql_connection_pool_size (if using mysql): Defines the connection pool size to MySQL. Default value is 10.
  • mysql_minimum_idle_connections (if using mysql): Minimum number of idle connections to be kept active. If not set, minimum idle connections will be same as the connection pool size. By default, this is not set.
  • mysql_idle_connection_timeout: (if using mysql): Timeout in milliseconds for the idle connections to be closed. Default is 60000 MS.
• Check if you have access token blacklisting enabled in the backend SDK. The default is false, but if you have it enabled, then it means that every session verification attempt will query the supertokens core to check the database. This will add latency to the session veirifaction process and increase the load on the core. If you want to keep this to true, consider making it so only for non GET APIs for your application.
• You can increase the value of access_token_validity in the SuperTokens core. It sets the validity of the access token. Default value is 3,600 seconds (1 hour). The lower this value, the more often the refresh API will be called, increasing the load on the core.