Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JS index loads very slow when authad is used #138

Closed
ghost opened this issue Oct 5, 2015 · 7 comments
Closed

JS index loads very slow when authad is used #138

ghost opened this issue Oct 5, 2015 · 7 comments

Comments

@ghost
Copy link

ghost commented Oct 5, 2015

The combination of JS mode and authad as authentication method makes indexmenu very unresponsive. Building the cache for the first time (first login) and every single save of a document lasts round about one minute in our environment with httpd using 100% CPU time.

I could break it down to exactly this combination of JS and authad. Turning of JS or switching the authentication backend solved the problem. It seems not to be any special active directory behaviour as the old ad authentication plugin still works, same to ldap or local users and groups.

Dokuwiki 2015-08-10a "Detritus"
indexmenu as of 2015-08-26

thanks & regards
Tim

@MrLokans
Copy link

I'm also having this issue: xdebug profiling showed that a lot of time is spent on syntax_plugin_indexmenu_indexmenu->_search_index method from indexmenu.php file. Also during the page load styles are not applied for the indexmenu for some time.
Here I attach the screenshot of KCacheGrind profiling (not sure if I'm allowed to attach whole profiling output due to NDA.)
dokuwiki_profiling

Best regards, Anders.

@Klap-in
Copy link
Collaborator

Klap-in commented Mar 29, 2016

Interesting info.
How many entries do you have in the tree displayed by indexmenu? I guess 229 entries?

@MrLokans
Copy link

Well, there are not too many first-class entries, but common structure is really nested and there are more than 200 entries in the indexmenu in general. Is 229 some 'magic number' that should be took in consideration?

@Klap-in
Copy link
Collaborator

Klap-in commented Mar 30, 2016

That number I guessed was based on the numbers from profiling.
There are no limits known.

about 200 entries sounds not that large, but maybe it is doing individual expensive calls via the AD...
but looking at the functions that get large processing times in the profiler, I cannot discover were that expensive call have happened.

All the functions that have the longest times have something with obtaining metadata.
Which could be relatively slow due to hard disk access, but that are actions that are performed for all search actions to fill the indexmenu list, and I don't see why it should slowdown if using authAD.

@splitbrain or @michitux do you have helpful suggestions what could be a relation between slow indexmenu and authAD?

@splitbrain
Copy link
Contributor

I had performance issues with indexmenu and authad at a customer before but couldn't pinpoint the problem either. Trouble was that it only happened for certain users but not all. But as I said I couldn't figure out what happened (debugging on a live system through another user's account made things more difficult).

@Klap-in
Copy link
Collaborator

Klap-in commented Jul 11, 2020

Recently some caching is added to auth plugins. Maybe that improve the combination of this plugins as well.

@Klap-in
Copy link
Collaborator

Klap-in commented Jul 10, 2021

Closing this, as probably the performce issues are in the communication with the ad part. That is a part that is not part of this plugin.

@Klap-in Klap-in closed this as completed Jul 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants