>> beside the list of requirements of ken, maybe someone can point me to a >> wiki which is fast. most of the wikis i have tried so far are >> incredible slow. and with slow i mean really user-get-bored slow during >> browsing the wiki and in the end noone uses it. > > I suppose this begs the questions:
you are right, i should have provided all these. i hope my - still bad - hangover from yesterday excuses this at least a little bit :) > Which ones did you use? we have tried several wikis and after some testing we have chosen the fastest one with an mysql backend. i am sorry, but this lies a year back and i cannot remember the name of the actual wiki. during the tests we had no real problem with the performance. everything was fine until the number of users increased (caused by the popularity of the tool, which at least showed that we have made at least the right decision for a useful wiki :))). we have used several tools for sql-monitoring and with the help of the tool we found out that the wiki makes a huge number of sql-selects and in combination with a bad db-design (no/wrong index and much more like this) the load of the server was always at the ceiling and above. tuning mysql didnt help and separating the wiki-server from mysql-server just moved the load to the mysql-server. at this time the rdbms supported were mysql and postgresql, but none of them were fastenough to handle the sql-requests. from my point there was no way to improve the performance of the wiki and in the end the wiki-project was stopped. > What sort of hardware were you using? the hardware was a typical for a server for a small company an x86 with 2mhz, 1 gig ram. because the server was already in the company, some guys brought up the idea to setup a wiki for team-communication and as a kind of FAQ. the server was IMHO fast enough to handle the small load and the server is AFAIK (i have left the company about 1,5 years ago) still in use and provides now services like proxy, webmail, and much more. so maybe someone knows a wiki (preferable with db-backend and not a file-system based on) that is faster and can handle more than only 2 concurrent users. br, gottfried -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
