Scalability

I'd like to get some experiences with very large installations. Maybe from people who converted existing documents to DokuWiki. Please indicate the Dokuwiki version you're using, as Dokuwiki continually strives to improve its performance.

What does find ./data -name '*.txt' | wc -l say?

Note To give People some idea how to rate your experiences, pure Size is not enough. Please post some more information about your environment: Which Version of DokuWiki are your using, what kind of Hardware is dokuwiki running on, is it a shared or dedicated server?

• ./data/*txt = 986 items, 6.6MB and ./media/* = 853, 227MB. (Update, 17/04/08: > Now up to 1893 pages and still going strong) Intranet installation of 55 users across three locations. Running on FreeBSD. Lovely system! Our users are continually discovering new ways to put it to work. At this size, it would be great to have a more granular search system (ie, search whole wiki, or just a particular namespace). I love that Dokuwiki is not database driven - it's great to be a able to manipulate the page content using standard unix tools. – Nick Fahey, 23 Aug 2007
  • Read search - namespace search is possible — Andreas Gohr 2007-08-23 11:08
• 187 documents (1.3M) on the UbuntuUsers Wiki – no problems. – MANY pages. We switched to MoinMoin because of the better performance and API Design.
• 159 documents (788KB), intranet, 6 users – everything works fine.
• 312 documents (802KB data/ and 2079KB media/), intranet, 5 users – runs smoothly.
  The search for one of the most often found words is executed in less than 1sec, generating a 141KB HTML page, while running an Anti-Virus program and other software (since Apache2 on Windows runs on a workstation instead of a dedicated server). Still, this is not a very large WikiSite.
• 173 documents (1.2MB), here at splitbrain.org.
• 201 documents (1.5MB data/ 9MB media/), http://www.maisenbachers.de/dokuw. Works like a breeze, nothing to complain about, no performace issues noticed so far ( ~9 GB Wiki-traffic in Oct.04)
• 973 documents (7.3MB), intranet with 12 users – works fine and no performance problems
• 7,733 documents (23.4MB), on single user system, searches > 5 minutes. On hosted server removed search facility and replaced with another. Even excluding 6632 documents (18.6MB) having huge problems with Web spiders such as Google, effectively creating a denial of service.
• 94 documents, (190k), works fine but search allocates more than the default 8MB of space allowed for PHP scripts so needed to tweak php.ini.
• One of my files was 253kb, and failed to display, presumably the parser timed out while reading the raw text file. No issues with the general data tree, which spans several meg over a half-dozen namespaces.
• 780 pages (3.6MB), working just fine. Search code in newer versions a big improvement!
• 295 pages (1.25MB) + 1.8MB media data, works fast and reliable. Very heavy usage of ACLs, users/groups and user private groups. The website is used as a normal website (for external users) and as an collab tool for different user groups and purposes. It grows very fast (+20 pages a day) and I am very about the usage of DokuWiki.
• 650 pages (5.9 MB) Shared host; serves approx. 6000 pages a day on dokuwiki. The current version 20050922 works fine, with feed caching and better search engine. The older version had some performance issues on those two points.
• 1477 pages (13.2 MB), intranet with 1-2 users (being tested for scalability) - Dedicated dual-processor server w/5GB RAM and eAccelerator. Searches are slow, but almost manageable. Viewing namespace indexes is almost impossible, and I get frequent PHP timeouts even after increasing the timeout value to 60 seconds.
• 1496 pages (11.6 MB), increasing (slowly) at the rate of about 10 per day. 80 users, spread across three continents. Shared dual-processor server (Microsoft IIS). Search is problemmatic across namespaces, but otherwise very few problems.
• 325 pages (14.5 MB), 50 users, on a dual-proccessor 2.8 mhz opteron, with 1 GB RAM, Opensuse, PHP 5, no problem, work fine.
• Wiki: 5588 pages (31 MB wiki source) + 1712 images (196 MB media data). Hardware: 1.4GHz AMD Athlon + 256 MB RAM. DokuWiki version: 2005-05-07. Suggested search mode: download the GZIPped wiki source files (*.txt) made by cron, unzip, then use grep or other desktop software :).
• 1500 or so pages (10.66 MB), shared (hosted) Linux server, PHP 5.1.4, latest DokuWiki. NO problems; search is good.
• 2000 pages and 2.5gb media over 6 dokuwiki installs on a single server - RHEL 4, twin 32-bit intel xeon CPUS, 8gb RAM (server also runs various static web content), search disabled, caching enabled. Very fast and responsive.

• see performance for a discussion how to improve performance during coding
• Maybe also interesting: DokuWiki vs MediaWiki benchmarks

• Are there any hints, how to improve DokuWiki during runtime?
• Does somebody has an idea which elements of dokuwiki are limiting the above experience at the moment?
  • The search is always going to be slower than SQL-based Wiki software, because DokuWiki's search has to parse a bunch of text files rather than simply performing a SQL query.
    • A plugin giving Dokuwiki the ability to use SQL for the search engine would be nice…
• I would think you could build something on top of Lucene that could be installed alongside DokuWiki and do a good job on searching. You could also try something like Swish-e, as described in How to Index Anything. Work has been done on integrating this with PHP, which gives you a starting point. PHP Search Engine Showdown is also worth a read.
• Just an idea: Dokuwiki pages are in server files; there are good search engines for files (e.g. Google Desktop). Anybody taking a test drive ? You'll have to extract data from Google Desktop caches on the server.