This page hosts some example IdP throughput numbers for some environments. Every environment will be different and this should be used as an estimate, not as a substitute for your own load tests.
...
CPU load is primarily determined by the number of logins per second your IdP will experience at peak load due to the cryptography of signing and encrypting assertions. Latency, when there is enough CPU, will be heavily influenced by the response time of the data sources that the IdP communicates with when authenticating users and acquiring attributes. RAM consumption is primarily determined by the number of concurrent login sessions each IdP node will keep, which is itself a function of session storage and replication choices, followed by logins per second and session duration. Total user base size tends to be an issue for upstream data sources to worry about and not a primary factor for load on the IdP.
...
| Name | Date | Logins / day | Hardware or VM | OS | Memory | JVM Container | Default LoginHandler | Clustering | Nodes | Cluster Method | SSL Offload | Loadbalancer |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| iup.edu | 10/2013 | 20k - 40k | vm | RHEL-5 | 6g | Tomcat | Username/Password | yes | 2 | Terracotta DSO | yes | yes - vm |
| washington.edu | 06/2017 | 140k | vm(6) | rhel | 4g | tomcat | RU (pubcookie) | yes | 3 | proxy | apache | DNS |
| cmu.edu | 12/2013 | 30k | vm | RHEL | 4g | tomcat | Username/Password | stateless | 3 | F5 | F5 | F5 |
...