ssh twice as fast on second try with sssd configuration (1st = 0m0.425s vs, 2nd = 0m0.199s)

I have about 15 servers I am trying to configure the optimal sssd configuration on. I am almost there but I cant figure out why after a period of time of not touching the boxes ssh is slow and then on the second attempt right after its twice as fast... Then if I wait 5 or 10 mins its twice as slow again... I am suspecting caching but I configured everything to the best of my knowledge and I have researched a lot and cannot find any better configs.

OS = RHEL 7.x

here is my sssd.conf....

1 - any ideas on how to make the first ssh attempt always as fast as the second? Id like it always to be as fast as local auth.
2 - any expert comments on potential problems with my configuration
3 - any further performance enhancements I can add?

What I think is happening is after the 5 mins it needs to re-cache? But I thought I told it to refresh its cached entries at 5 minutes? My config also says to only hold the cached entries for 4 days right? Shouldn't it only be slow again if I login again after 4 days?

[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam, ssh, autofs
domains = EXAMPLE.COM
#debug_level=9

[nss]
filter_groups = root
#Enter all the FIDs here for the specific environment "filter_users = "
filter_users = root
reconnection_retries = 3
entry_cache_nowait_percentage = 75
#debug_level=9

[pam]
reconnection_retries = 3
offline_credentials_expiration = 3
offline_failed_login_attempts = 3
offline_failed_login_delay = 5

[domain/EXAMPLE.COM]
cache_credentials = true
account_cache_expiration = 4
entry_cache_timeout = 400

description = LDAP domain with AD server
enumerate = false
default_shell = /bin/bash
fallback_homedir = /home/%d/%u
ldap_idmap_range_min = 200000
ldap_idmap_range_max = 2000200000
ldap_idmap_range_size = 100000000
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad

ad_domain = EXAMPLE.COM

ad_server = SERVER1,SERVER2,SERVER3
ad_backup_server = BACKUPSERVER1,BACKUPSERVER2,BACKUPSERVER3

# ignore_group_members makes getgr* omit the members field
# this vastly improves performance for things like id and sudo
# but it may need to be disabled if any of your applications
# expect to be able to read group memberships.
ignore_group_members = true

#For troubleshooting
#debug_level=9

#Access
access_provider = simple
simple_allow_groups = GROUP1,GROUP2,GROUP3
#simple_allow_users =

i experience the same on my box, and i don't think there's anything to do about it.
on my server it actually got worse after encrypting the drive.
first connection takes a long time, after that it's near-instant.
i think it has something to do with buffers...
the only solution i could think of would be to make it always as slow as the first time. consistency.

What does Red Hat say?

1 members found this post helpful.

It rather sounds to me like the process is simply being "swapped out" on a busy machine. When it becomes active again, the OS must swap it back in again, and that takes time. Next time around, the process hasn't been swapped back out yet.

Perhaps this behavior actually has nothing at all to do with the configuration parameters that you're so busily tweaking!