Q: What is the largest PmWiki site in number of pages?

Pm: Of course there’s no theoretical limit to the number of pages, because of the way that PmWiki organizes them.

The practical limits are on the number of files that can be organized in a single directory (wiki.d), and the time it takes to search through the pages. As a couple of reference points, the SciTechWiki (http://www.sci.tamucc.edu/wiki) currently has 1649 pages and the TAMUCC Wiki (http://www.tamucc.edu/wiki) has 4500+ pages and both of them seem to run without any problem; even searches don’t seem to take unreasonable amounts of time. Both of these wikis are running under Red Hat Linux. I know that under RH Linux I have some directories with 5000+ files in them with no major difficulties (mailing list archive directories), so I don’t think the OS will pose a barrier on PmWiki at least to that point.

However, I did think about these problems a bit when designing PmWiki and here’s what I’ve decided thus far. First, as far as directory limitations go, I designed the $PageFileFmt, $WikiDir, and $WikiLibDirs variables so that an admin can organize the files into an alternate structure other than just “wiki.d/Group.Pagename”. For example, $PageFileFmt could be changed to ‘$Group/$Title_’ or '$Group/$PageName' and files would be stored as “wiki.d/Group/Pagename” or “wiki.d/Group/Group.Pagename”, which would reduce the overall number of files in any single directory. Something would still have to create the directories for the groups, but this isn’t a big problem. But even if this approach doesn’t break things up sufficiently (e.g., a single group with thousands of pages) there are still other options—with a couple of very minor extensions the files can be organized into directories based on the first character(s) of the title, as in “wiki.d/P/Group.Pagename” and “wiki.d/W/Group.WikiWord”. This would spread the load out among more directories as well.

And, of course, I could always look at relational databases or other indexing schemes if it became necessary to do so. However, I like simplicity, and this is definitely one of those areas where I’ve chosen to avoid gratuitous features; i.e., take the simple approach for now and build the complex implementation only when a real demonstrated need arises, at which point the real parameters of the problem are better known. I’m also quite comfortable that if we need to change the back-end storage model at some point it’ll be easy to create a migration path from the existing schema to a new one.

Note: SearchWiki is becoming more sophisticated as PmWiki is growing. Advanced search features are being added to PmWiki. If the search features included in PmWiki are not sufficient, there are already some excellent site indexing and retrieval systems available, and it’s much more effective to make use of the existing packages rather than try to duplicate that functionality into PmWiki.

« PmWiki.Contributors | PmWiki.DocumentationIndex | »