moinwiki/moin

Slow performance: up to 10s per page

sebix opened this issue · 10 comments

The load time of one of our wikis has significantly decreased over time as more and more pages were added. The wiki still has only 69 pages, but the load times vary between 2s and 10s, which significantly reduces the user experience.

On the same server, we have an even smaller wiki with the same code base and only 13 pages, with load times of 0.7-1.7s.

Because of this correlation, we guess that the performance degradation is related to the number of pages.

Are there any performance-related things to improve in the settings?
Are the any logging/debugging options to investigate the cause?

We are currently on version 5d33343

Can you try to run a 'moin index-optimize' command when nobody is updating the wiki? In #1310 this fixed a performance issue.

Before and after running that command you can list the index files with 'ls -l wiki/index' to compare the size and number of index files.

Thank you for the tip.

The number of files decreased from 20 to 6 and the total size of the directory from 62M to 56M.
The load times are now indeed below 2s, which isn't great but a big relief.

I guess we need to run that command on a regular basis.

@sebix but you hopefully don't run moin as cgi?

With a persistent python/moin2 wsgi process, 2s sounds way too much for a normal/simple page.

Of course, on special pages and pages with expensive macros, load time depends very much on what is actually done there.

@sebix but you hopefully don't run moin as cgi?

With a persistent python/moin2 wsgi process, 2s sounds way too much for a normal/simple page.

The setup uses apache2 with WSGI.

Of course, on special pages and pages with expensive macros, load time depends very much on what is actually done there.

The mentioned load times were all for simple pages with markdown or text only, without macros. /+index/ and /+history/ actually have the same load times (1.5s-2s).
Markdown seems to have a very little effect of about 0.2s or so.
Calling non-existent pages is quicker by about 1s: 0.8s.
Calling, for example, /Home or /+index/Home directly from localhost to exclude any possible delays of TLS, reverse proxies, etc., the load time is consistently 1.7s.

try to run a 'moin index-optimize' command when nobody is updating the wiki?

Is there an easy way to disable that people can update the wiki? Or: What happens if somebody updates it while the command runs?

Is there an easy way to disable that people can update the wiki? Or: What happens if somebody updates it while the command runs?

No, I don't know of any other way to disable updates other than stopping the web server. In the case of optimize-index, this shouldn't really require an offline state, but I would always recommend running it at off-peak times.

@sebix, can you please test again with the latest update? In the last few days, some improvements have been made to speed up simple items. Perhaps we can close this issue for the moment?

Do not forget to clear the browser cache before testing with the latest version.

@sebix, are you using the discussion feature:

image

If not, you can deactivate the feature with following additional setting in wikiconfig.py:

    # deactivate discussion feature
    supplementation_item_names = []

This will save some additional index queries.

sebix commented

@sebix, can you please test again with the latest update? In the last few days, some improvements have been made to speed up simple items. Perhaps we can close this issue for the moment?

Yes, the performance is slightly better: 1.8s -> 1.7s.

@sebix, are you using the discussion feature:
If not, you can deactivate the feature with following additional setting in wikiconfig.py:

    # deactivate discussion feature
    supplementation_item_names = []

This will save some additional index queries.

yes, that brings another small improvement of 1.7s -> 1.6s

Note, even that is a slow system 1.6 seconds is still too slow for a tiny production wiki. If there is a linear dependency on the number of pages, it will only grow. Just from the technical structure, there shouldn't be an increasing effort for accessing one page depending on the total number of pages.