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.
What to Watch For
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 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.
CPU load is the principal bottleneck in most IdP deployments.
AWS EC2
A single c1.medium instance running the IdP in Jetty without Terracotta and a million user records and a standard set of attributes in an LDAP directory with authentication randomly choosing one of them can handle roughly 65 transactions per second. Optimizations can raise this to 80 tps. Memory(roughly 50% of "physical" memory is used by java) and disk utilization(negligible) are not considerations even with tens of thousands of concurrent authentication sessions, but situations can arise where the garbage collection with excessive user session objects collides with limited total memory, resulting in a long freeze of the jetty process. With stateless clustering, this will scale linearly. With stateful clustering, performance is likely to be considerably different. A single c1.xlarge instance running in the same fashion can achieve 300 transactions per second and is not susceptible to freezes or crashing during garbage collection.