Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
On my site with ldap_data module activated, every page request leads to at least two ldap queries, a login leads to 4. This is because several other modules call the user_load() core function, which finally calls _ldapdata_user_load().
I don't know, whether this could be improved inside ldap_data.
The attached patch implements a static cache so only one ldap query should be fired out per every user load on the page load. Moreover, it has a configuration setting to cache, i.e, not query ldap to sync data for other users than the logged in user. This is useful for pages where multiple users are loaded and where each of those users were synced on the page load.
I don't understand how I can test the synchronization option. What I did is: I changed the email address in MySQL. After login that is synchronized from LDAP. I changed it again and went to several pages, including my account and the LDAP data page, but nothing is synchronized, regardless whether I check Cache LDAP queries or not. Also I went to the user page as admin, but nothing was synchronized.
I will keep the patch and look for new issues. Thanks.
It used to be that on each user load, the ldap was queried and drupal profile was synced with the ldap data, which generated a lot of ldap traffic.
Now when cache is enabled, the synchronization will be done only for a currently logged in user. So if you change your ldap data and login to drupal, drupal profile should sync (pick a new ldap data), However, if you look at other users accounts as an admin, their data will not be synced until they themselves will log in.
Not exactly. It will generate the traffic just for the user which is signed in. So if information in the LDAP is changed while the user is browsing the site, it will be immediately synced on the next page load. But the ldap information will not be synced for other users, which means if I am a user x and are looking at profile of user y, the y user's profile will not be synced until user y logs in to the site.
Comments
Comment #1
arnd commentedOn my site with ldap_data module activated, every page request leads to at least two ldap queries, a login leads to 4. This is because several other modules call the user_load() core function, which finally calls _ldapdata_user_load().
I don't know, whether this could be improved inside ldap_data.
Comment #2
miglius commentedI think we need a static caching to reduce ldap queries.
Comment #3
aren cambre commentedAgreed. LDAP queries should only be needed the first time something is checked, not on every page load.
Comment #4
miglius commentedThe attached patch implements a static cache so only one ldap query should be fired out per every user load on the page load. Moreover, it has a configuration setting to cache, i.e, not query ldap to sync data for other users than the logged in user. This is useful for pages where multiple users are loaded and where each of those users were synced on the page load.
Comment #5
miglius commentedThis patch has a bug fixed.
Comment #6
arnd commentedAfter login I now get 1 LDAP access per page.
I don't understand how I can test the synchronization option. What I did is: I changed the email address in MySQL. After login that is synchronized from LDAP. I changed it again and went to several pages, including my account and the LDAP data page, but nothing is synchronized, regardless whether I check Cache LDAP queries or not. Also I went to the user page as admin, but nothing was synchronized.
I will keep the patch and look for new issues. Thanks.
Comment #7
miglius commentedIt used to be that on each user load, the ldap was queried and drupal profile was synced with the ldap data, which generated a lot of ldap traffic.
Now when cache is enabled, the synchronization will be done only for a currently logged in user. So if you change your ldap data and login to drupal, drupal profile should sync (pick a new ldap data), However, if you look at other users accounts as an admin, their data will not be synced until they themselves will log in.
Comment #8
aren cambre commentedModifying issue to make it more accurate. Once a user is signed in, there generally should be no more LDAP traffic for that user.
Comment #9
miglius commentedNot exactly. It will generate the traffic just for the user which is signed in. So if information in the LDAP is changed while the user is browsing the site, it will be immediately synced on the next page load. But the ldap information will not be synced for other users, which means if I am a user x and are looking at profile of user y, the y user's profile will not be synced until user y logs in to the site.
Comment #10
aren cambre commentedThanks. I just talked with my AD system administrator, and turns out this is fine and not unusual.
I switched the title around to make this a more generic issue about caching than my specific problem.
Comment #11
miglius commentedCommitted.
Comment #12
miglius commentedChanged naming from caching to synchronization options and added additional option to sync data only on the login.
Comment #13
eriktoyra commentedWould this patch be possible to use with/port to the 5.x-1.3 version? I'm struggling with some serious performance issues because of this problem.