Jupyterhub Can a large number of users start the service at the same time

I used the API to start each user’s server and an error occurred
tornado.web.HTTPError: HTTP 429: Too Many Requests (Too many users trying to log in right now. Try again in 60 seconds.)

When I start the user’s server with the API every five seconds, it all works
I would like to know how many concurrent requests JupyterHub can support. How can I increase the concurrent requests
My JupyterHub is deployed on AKS K8S 1.19

You’re getting rate limited which is a safety feature to avoid crashing the hub, see the config docs:

https://jupyterhub.readthedocs.io/en/stable/api/app.html#jupyterhub.app.JupyterHub.concurrent_spawn_limit

I would like to know how many concurrent requests JupyterHub can support.

There are a lot of variables here so there isn’t any one right answer. It depends on your setup (are you using zero-to-jupyterhub-k8s with kubespawner?), the image and resource limits you’ve put in place, if you’re pre-pulling images on the user nodes, if you’re pre-scaling user node capacity with placeholders:

https://zero-to-jupyterhub.readthedocs.io/en/latest/administrator/optimization.html#scaling-up-in-time-user-placeholders

Etc. There have been several threads related to this topic and my team has developed some open source tooling that we use to stress test our deployments:

You might find that useful for your testing. If nothing else you can at least refer to the other previous forum threads linked here:

1 Like

Also depending on what you’re using in your setup (z2jh/kubespawner) you may want to disable this setting:

https://jupyterhub.readthedocs.io/en/stable/api/spawner.html#jupyterhub.spawner.Spawner.consecutive_failure_limit

z2jh defaults that to 5:

For us we had to disable that because during a high load event where lots of users were logging in at once we were getting consecutive spawn failures (sometimes) if for example the node auto-scaler was slow to catch up and spawns were failing waiting for an available node. Restarting the hub in that case didn’t help and in our environment and usage patterns it’s an expected scenario if we’re not pre-scaled enough so we just disabled that config.

1 Like