General Guidance on IdP Environment Sizing

[Peter Schober]

* Ryan Tapp <Ryan.Tapp at csulb.edu> [2018-09-27 20:54]:
> Our load issues began with an environment consisting of two v3.3.3
> IdPs (RHEL7, Tomcat 8.5, JDK 1.8.0_181) and three LDAP servers (AD
> LDS), everything behind a network load balancer.  Typical fixes
> didn't seem to affect it and the problem comes and goes but
> correspond to peak traffic times.

This probably just means your LDAP implementation sucks big time. ;)

I haven't dealt with LDAP servers in a long time, but some 8 years ago
when that was still my job and I was building a new LDAP system for
Univie I did some performance testing with slamd. I kept one such
report around:
https://homepage.univie.ac.at/peter.schober/slamd/jobs/job_20101208004537-80776032.html
So my 3 servers behind a loadbalancer could handle a sustained ~11000
searches per second (that's almost 3 orders of magnitude higher than
what Jim's IDPs handle "at their busiest"), with 1.6ms avg response
time, and zero errors. Including STARTTLS and doing sub-tree searches.

That was using OpenLDAP 2.4 on GNU/Linux, nothing special. (That would
probably have been on then-current mid-sized Compaq/HP DL380 systems,
including spinning rust.)

Main difference between that test and SAML SSO was that I was testing
for the mail routing case, so the above had randomized queries with
only 1/100 of them hitting an existing record (AFAICT from that
report).  But I don't think those cache misses would skew the test
results so badly the results couldn't have been repeated with queries
for near-100% existing records.

So given that 8 years have passed since that, with much more RAM and
even Solid State Disks now being readily available, I'd expect quite a
bit more performance from an enterprise-scale directory service.
There's certainly no need to be a thousand times slower than a decade
old open-source system. ;)

-peter