This page tries to collect some information about how DokuWiki scales when it becomes “big” and what the limiting factors are.

95% of everyone considering using DokuWiki will not even need to bother reading this page. Unless you want to run a public wiki for a very popular topic or want to use some very underpowered hardware performance should not be a problem for you.

The number of pages is not limited. Some people have hundred of thousands pages in their wiki and no problems at all, but it all “depends”.

Your Filesystem will have limits. Commonly there's a limit on how many files can be in a single directory. DokuWiki uses directories for namespaces. So if you namespace your pages you can mitigate the problem. Keep in mind that each revision of a page creates its own file in a directory.

add info about file/directory limits of different file systems

Of course you are limited by disk space. Of course media files, pages and older revisions will take up space. However the data/cache directory can grow quite big over the years - depending on the wiki size a cache directory of a few Gigabytes is not uncommon. By definition everything in the cache directory is optional so you can delete it's contents on the penalty of a small speed reduction until the cache is refilled.

Basically everything said for pages is also true for media files.

Since the media manager does not do paging (currently), it is recommended to make use of namespaces to organize the mediafiles. Loading hundreds of thumbnails is going to be slow.

Mediafiles are resized through PHP's libGD mechanism by default. A more efficient way may be to use ImageMagick via the im_convert option.

In the early days of DokuWiki, search used to be the limiting factor. Back in the day, a search would simply go through all available pages and look for the searched term - the more pages you had, the slower that was.

Today, DokuWiki uses an index based search. That search index makes searching much faster since a term is simply looked up in the index and the results are immediately available. The index is word based, sorted by word lengths. So a search for a full word is faster than a search for a word part (using the * syntax).

In theory, the limiting factor for the index based search is the memory_limit in your PHP setup. Part of the index is a list of all pages in the wiki - this list needs to be loaded completely into RAM. In reality I never heard anyone having this problem.

DokuWiki relies heavily on files for storing everything. The most significant speed update you can achieve is using an SSD for your setup.

Modern Operating Systems will cache disk access to frequently used files in memory. Them more rAM your server has, the more is available to be used as file system cache.

DokuWiki does a lot of scanning for different files that may not exist. For example we check each plugin directory for the existence of a script.js file. Those non-hits may add up to some significant amounts on very busy Setups.

We try to avoid whole directory scans as much as possible, but sometimes it's necessary. The readdircache option may help mitigate the problem somewhat.

The reliance on the filesystem however makes it extremely difficult to run a DokuWiki on multiple servers. For performance reasons, tt is not recommended to use a network filesystem.

Disabling access time recording in your filesystem may be a good idea to decrease IO load.

Each and every new PHP version gets better and faster. There is a huge difference between PHP 5 and 7, and some smaller differences between the different minor versions of 7. Always use the best version available to you!

The Webserver needs to pass requests to PHP. We recommend using mod_php or FPM for that. FastCGI is slower. Unfortunately FastCGI seems to be the only option when using IIS, so if you can use something else - do so.

The above already gives a few hints on where you may experience bottlenecks. Here is a list of further reading on how to mitigate problems when they occur.

• use better hardware - sometimes simply upgrading to a better server (more RAM, SSD) is the simplest solution
• use a dedicated search engine
  • sphinxsearch
  • googlesearch
  • solr
• improve end user caching
  • smartcache

• FAQ: How about using a Database?
• DokuWiki vs MediaWiki benchmarks

We'd like to collect some real world number of “big” installations here. If you are running a larger installation, please let us know about your setup here. Especially if you ran into scaling problems and solved them.

dokuwiki.org has currently 4859 pages with about 15k pageviews per day on average
still on PHP 5.6, Linux/ext4 with noatime, Apache + FPM
running on a i7-6700 CPU with 64GB of RAM and SSD. That server is running all kinds of other DokuWiki services besides the wiki itself. Everything's fine and snappy.
— Andreas Gohr 2019-02-28 12:23