Question

We have been evaluating Twiki for implementing a project portal in our organization. So far our experience with TWiki has been good. However before we take it forward, we would like to get a few things clarified. We have a few questions and the same are given below:

Questions:-

---

1. Is there any constraint on number of webs that can be created in a given TWiki installation?
2. Is there any constraint on number of users who can access a particular TWiki installation at a given time? Are there any issues with the performance when more number of users connect to TWiki concurrently?
3. Are there any instances of a TWiki installation crashing? If yes, how can we restore the installation back? Are there any chances of losing the data.

Answers to the above questions will help us a long way in going ahead.

• TWiki version: TWiki20030201
• Perl version: v5.8.0
• Web server & version: Apache 1.3.27
• Server OS: Windows XP
• Web browser & version: IE 6.0
• Client OS: Windows XP

-- SampturUmashankar - 06 Jun 2003

Answer

Let's see if people can collectively answer your questions. I'll make a start here:

-- TorbenGB - 06 Jun 2003

Generally, Linux-based TWikis on Pentium III or better hardware seem pretty fast, while Windows based TWikis really need mod_perl to provide good response times (just based on my experience). However, this doesn't address scalability. Using ModPerl will greatly improve the scalability of TWiki, as well as improving response times. Also, the CacheAddOn would help if mod_perl can't be used, and perhaps even if it can, because TWiki is quite CPU-intensive for page viewing.

-- RichardDonkin - 07 Jun 2003

---

1. Is there any constraint on number of webs that can be created in a given TWiki installation?
   • No, TWiki can have and handle an unlimited number of webs. There are practical limits though:
     • Most file systems only allow a finite number of subdirectories in any given directory, so your operating system sets one (very very large) limit, and since TWiki uses a subdirectory per web, the number of webs you can have.
     • Say you have 500 webs in your TWiki. How are users ever going to find their way to the web they are looking for?
     • You might run out of disk space quickly.
2. Is there any constraint on number of users who can access a particular TWiki installation at a given time? Are there any issues with the performance when more number of users connect to TWiki concurrently?
   • TWiki does not have any such limitations. But your web server has. Any web server can only handle a finite amount of concurrent users, so if you have a lot, then you might need a bigger server. More users equals more load, equals a need for a more powerful web server.
     • As long as you can run it all on a single server, TWiki won't complain. TWiki was not built for clustered solutions though, but I can't imagine you'll need that. (If you do, we'd like to hear about it!)
3. Are there any instances of a TWiki installation crashing? If yes, how can we restore the installation back? Are there any chances of losing the data.
   • It's always wise to take backups, regardless of how stable you think the software and the hardware is. If you have a good backup routine, your TWiki data should be as safe as any other data.
   • TWiki itself isn't prone to crashes, at least I've never experienced or heard about any TWiki crash. It's really just a handful of CGI scripts, when you think about it.
   • If anything crashes, then it could be the web server software, the operating system software, or even the hardware.
   • Bottom line is: all software has bugs. Never think there are no bugs. Sooner or later, all computers will crash. But if you've been thorough (taking backups, for instance), then nobody will be affected when it happens.

---

1 Is there any constraint on number of webs that can be created in a given TWiki installation?

You wrote that you're building a portal. So I'm guessing that you're a large company or an ISP or some other type of organisation that has a large user population. Instead of building a web per user (which would require lots of very small webs), you could consider putting them all into a user web. Then each user would just have their own user page eg Main.FrancisLiu that they could use for their home page on the portal. All the user pages are going to be created in the Main web anyway, so you may as well use them.

This means, that one of your primary concerns will be how apache performs with lots of small files in a given directory (the Main web that holds all the details of your users). The Main web is going to be read whenever a user reads/modifies a page...

-- FrancisLiu - 08 Jun 2003

Hello Torben, Richard & Francis.

Thanks to all you for your inputs. We will be able to go ahead based on your comments.

Regards,

Umashankar

-- SampturUmashankar - 09 Jun 2003

It seems that you are using Windows XP servers (or Windows 2000?) - this is not a great option for performance due to the high overhead of running CGI Perl processes, so using ModPerlOnWindows would be mandatory.

If you are are able to use Linux servers, the ReiserFS filesystem (Google:reiserfs) is particularly good at handling many small files (and is included in most Linux distributions) and some other filesystems described in that article may also handle this better than the default ext2 filesystem (on Linux) or ufs (on most Unixes). ReiserFS attempts to avoid the situation where many small files must be combined into a single larger 'database' file purely for performance reasons.

Recovering from a crashed server is also easy with ReiserFS or other journalled filesystems (Windows 2000 does have such a filesystem, NTFS, but in my experience it sometimes loses files on reboot after a crash). Generally, TWiki's use of plain text file formats would make it very easy to recover virtually all of a TWiki site in the event of some hardware crash that corrupts just a few pages - this would be much harder if it used a database.

For more platform considerations, see TWikiOn.

-- RichardDonkin - 09 Jun 2003