Is there interest in caching patch for authldap ?

[XANi]

I'm implementing dokuwiki in company I work in and we ran into a problem where adding LDAP auth changes rendering time for page from ~40 ms to ~200ms, and ~300ms if I enable Gravatars in bootstrap3 theme (I'm guessing because it calls getUserData() again to get user's e-mail).

So I've added a simple patch that basically caches whatever that function is returning and requests are back to ~40 ms:

@@ -150,7 +151,17 @@ class auth_plugin_authldap extends DokuWiki_Auth_Plugin {
      * @return  array containing user data or false
      */
     public function getUserData($user, $requireGroups=true) {
-        return $this->_getUserData($user);
+        $usercache = $this->cache->get("user_data::" . $user);
+        if ($usercache != null) {
+            return $usercache;
+        }
+        $userdata = $this->_getUserData($user);
+        if ($userdata == false) {
+            $this->cache->set("user_data::" . $user,$userdata,60);
+        } else {
+            $this->cache->set("user_data::" . $user,$userdata,7200);
+        }
+        return $userdata;
     }

The question is:

• would there be interest in patch doing that (+ of course make timeouts/server configurable)
• is authldap even a good place to put it, or should it be cached somewhere higher.

[Klap-in]

Implementing a cache is an improvement that is suggested in https://github.com/splitbrain/dokuwiki/issues/1577 as well. There it is suggested to implement it independent from the authentication backend.

If you could implement it according #1577 the caching is an useful contribution!

[XANi]

How would that have to be implemented ? As separate plugin ? If I understand it correctly (sorry, not a PHP dev), it can't be added to class DokuWiki_Auth_Plugin->getUserData because that function is overriden on each of the auth modules.

Other option would be adding generic cache functionality (possibly with different backends) and just pass cache backend object to auth module, but frankly I don't even know how to start that..

[nixcorn]

👍 for this. I had the same issue in our company; or I thought it's because of the authldap. We could improve the site loading performance with php-mbstring.

[XANi]

@nixcorn https://gist.github.com/XANi/db74322ca9a17963e82434d311a722c0 this is what I use, just install memcache on localhost

[Klap-in]

@splitbrain @Chris--S what are your thoughts about where caching should be implemented?

I see only a non-backward compatible approach: introduce an general dokuwiki function with caching which calls DokuWiki_Auth_Plugin->getUserData. This general function should be use everywhere instead of getUserData. This manner everything keeps working if it still depends on the DokuWiki_Auth_Plugin->getUserData. Other ideas?

Eventually this new function can be prepared for use of memcache, eventually via an event hook.

[XANi]

Note that for generic caching you will definitely want different caching length per type of data (or even type of auth backend)

For example you might want to cache existing user info for hour so all operations that need it (like viewing history of file) but only cache "misses" (user does not exist) for a minute, so if user is added in LDAP his info will show up in a minute, not in 2 hours.

Maybe something like DokuWiki_Auth_Plugin->cache protected variable that has DokuWiki_Auth_Plugin->SetCacheBackend function to set it, then assume every caching backend would have to have get & set like memcached lib ?

Then each plugin who needs it would have get() & set() easily accessible to it and timeout-related config could be kept within plugin

[Chris--S]

I tend to think userdata should only be cached in DW itself for the single page/call. Any decision on caching for longer than that should be down to the backend and any policies that go with it.

It may be reasonable to add caching to the standard auth class and individual backends can then decide to use/not use that caching.

Gravatar details probably should be cached for the session - which would be an issue for that plugin??

[XANi]

I tend to think userdata should only be cached in DW itself for the single page/call.

That could be default "dummy" caching backend; "just put it in RAM for that one request".

Gravatar details probably should be cached for the session - which would be an issue for that plugin??

Why ? how often does user change e-mail address ?

[Chris--S]

Gravatar details probably should be cached for the session - which would be an issue for that plugin?? Why ? how often does user change e-mail address ?

My point wasn't so much the cache expiry, but that caching the gravatar details should be the responsibility of the plugin.

[XANi]

My point wasn't so much the cache expiry, but that caching the gravatar details should be the responsibility of the plugin

Sure but slowness in it is caused by calling getUserData from auth backend. Making that cacheable fixes all plugins using it, making separate caching for gravatar fixes only that.

[splitbrain]

I think I agree with @Chris--S it would make sense to provide a caching mechanism but let auth plugins decide to use it.

[RaphaelWimmer]

I would definitely appreciate configurable long-term (i.e. several minutes/hours) caching of user info in the auth plugin. The LDAP server that I need to use for authentication adds 800+ ms latency to every page request. It is only queried once per page load, so caching only for a single page load wouldn't improve matters at all.

[calebjacobsonns]

I know this is old, but I am also in favor of caching user info across page loads/requests. We attempted to use authLDAP and it also added significant latency to each page load. Any new work on this?

[cvoltz]

In 2017, I used memcache with authLDAP to cache the results (similar to what @XANi suggested) but when I upgraded to PHP 7 in 2018, the performance improved dramatically enough that I backed out that patch. Given the lack of activity on this ticket, it is likely that there isn't much general need for the caching enhancement. You might have a problematic configuration that needs investigating. You could always implement an updated version of the memcache patch. It was pretty simple and work very well.

[splitbrain]

BTW. you may want to follow/finance/contribute https://github.com/splitbrain/dokuwiki-plugin-pureldap - it's where I ultimately want to join AD and LDAP access, including caching and performance automation. It currently implements basic AD features. See also https://github.com/splitbrain/dokuwiki-plugin-pureldap/blob/master/PHILOSOPHY.md