8 lines
3.1 KiB
Text
8 lines
3.1 KiB
Text
version=pmwiki-0.5.26
|
|
newline=²
|
|
text='''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: Main/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.²²%trail%<<|PmWiki.DocumentationIndex|>>
|
|
time=1072815523
|
|
host=24.1.44.14
|
|
agent=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
|
|
rev=21
|
|
post= Save
|