attachment
long_userlist.json

to put the dataset into a machine without the batch row limit, just run
curl -v 2 -H "Content-Type:application/json" 3 -H "Accept:applicaton/json"4 --negotiate -u : 5 --cacert /etc/ipa/ca.crt 6 -d @long_userlist.json -X POST https://hostname/ipa/json

part 1 of 3 for split long user list
long_userlist-1.json

attachment
long_userlist-2.json

attachment
long_userlist-3.json

attachment
long_userlist-4.json

This is bad but can we do something about it? Is there a way to profile it?

After some inspection, this is not as bad as originaly posted. I installed IPA directly on my LAptop, no Virtualization overhead and decent amount of resources. Tee same query now only requires 3 seconds to run, so I suspect the VM was running into memory constraints. I have a larger User data set (5k users) that I will try and see if it breaks things

After doing some profiling, I found the bottleneck was in the calls to the LDAP server. THe Virtual Machine was set up with one VCPU, which meant that there had to be a complete context switch and switch back before the RPC could return. When I added an additional VCPU to the VM, the bottleneck went away.

cache get_ipa_config() output in request context
freeipa-rcrit-759-cache.patch

Patch 759 committed as:

master: e1ef080

ipa-2-0: caab2aa

save a few hundred ms
freeipa-rcrit-804-perf.patch

master: b02b77f

ipa-2-0: f086503