few changes to performance and scalabillity docs

v2/community/supertokens-core/self-hosted/performance.mdx

@@ -10,17 +10,17 @@ hide_title: true
 # Tuning Performance
 
 If you are facing preformance issues, here are some tips to help you tune the performance of your SuperTokens setup:
-- The SuperTokens core is stateless and can be scalred horizontally. You can add more instances of the core service to handle more requests (behind a load balancer).
+- 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.
-- 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, 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.
-- You can tune the SuperTokens core performance by setting different values for the following configs in the config.yaml file, or docker env:
+- 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.
-    - `access_token_validity`: 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.
     - `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.
+- 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.

v2/emailpassword/common-customizations/core/performance.mdx

@@ -10,17 +10,17 @@ hide_title: true
 # Tuning Performance
 
 If you are facing preformance issues, here are some tips to help you tune the performance of your SuperTokens setup:
-- The SuperTokens core is stateless and can be scalred horizontally. You can add more instances of the core service to handle more requests (behind a load balancer).
+- 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.
-- 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, 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.
-- You can tune the SuperTokens core performance by setting different values for the following configs in the config.yaml file, or docker env:
+- 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.
-    - `access_token_validity`: 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.
     - `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.

v2/emailpassword/scalability.mdx

@@ -15,6 +15,10 @@ SuperTokens can handle 10s of millions of users and tenants (organizations). In
 
 ## SuperTokens core scalability
 
+:::important
+If you are using our managed service, the SuperTokens core is fully managed by us, and you don't have to worry about scaling it. This section is for those who are self-hosting the SuperTokens core service.
+:::
+
 The SuperTokens core service is designed to be horizontally scalable. This means that you can add more instances of the core service to handle more requests. The core service is also stateless, which means that you can add or remove instances without worrying about the state of the system.
 
 The core service is designed to be able to handle a high number of requests per second (RPS). The exact number of RPS that the core service can handle depends on the hardware that you are using, but in general, the core service is designed to be able to handle a large number of requests. 

v2/passwordless/common-customizations/core/performance.mdx

@@ -10,17 +10,17 @@ hide_title: true
 # Tuning Performance
 
 If you are facing preformance issues, here are some tips to help you tune the performance of your SuperTokens setup:
-- The SuperTokens core is stateless and can be scalred horizontally. You can add more instances of the core service to handle more requests (behind a load balancer).
+- 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.
-- 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, 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.
-- You can tune the SuperTokens core performance by setting different values for the following configs in the config.yaml file, or docker env:
+- 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.
-    - `access_token_validity`: 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.
     - `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.

v2/passwordless/scalability.mdx

@@ -15,6 +15,10 @@ SuperTokens can handle 10s of millions of users and tenants (organizations). In
 
 ## SuperTokens core scalability
 
+:::important
+If you are using our managed service, the SuperTokens core is fully managed by us, and you don't have to worry about scaling it. This section is for those who are self-hosting the SuperTokens core service.
+:::
+
 The SuperTokens core service is designed to be horizontally scalable. This means that you can add more instances of the core service to handle more requests. The core service is also stateless, which means that you can add or remove instances without worrying about the state of the system.
 
 The core service is designed to be able to handle a high number of requests per second (RPS). The exact number of RPS that the core service can handle depends on the hardware that you are using, but in general, the core service is designed to be able to handle a large number of requests.