Loading...
 
Skip to main content

Development


Scalability

I recently submitted bug#840397 to SourceForge (view bug)Question. My concern is scalability. Has anyone verbalized the scalability of tiki's wiki?

I have discovered that creating just 10 structures in my wiki can overhwhelm tiki. With 605 nodes, my 10 structures have resulted in over 5,000 rows in the table tiki_structures and over 27,000 rows in the table tiki_links.

The problem comes when I try to edit structures or edit categories. Either of those operations results in exhaustive queries to mySQL for every row in tiki_links, effectively breaking tiki. The browser will time out and tiki will seem to hang until the queries are completed.

Again, my concern is scalability. Has anyone addressed this? Do you think this issue is solvable or do I need to call Larry Ellison if I envision a Wiki with over 30,000 structured pages?

I have some new findings to shed additional light on this subject.
For one, I've found that editing structures makes exhaustve select calls to tiki_stuctures. I suggest that in the future tiki_structures only contain the names of structures, and that sub-structures have their own tables, to limit these kinds of exhaustive searches.

Secondly, I've found that tiki_links, alarmingly, grows exponentially with relation to the number of structures or wiki pages in the database. This is a huge scalability problem, especially given that there is select code which crawls through tiki_links.

Egads...I've thought about rewriting it myself but I don't think I can just yet. This is a big problem though imho.

I agree that this looks like a big problem, which alarms me somewhat. Especially since there seem to be other areas where performance is not great, specifically the forums and loading large pages into the Wiki.

Questions

  1. Would it make any difference if the structures were inverted (eg 600 structures with 10 nodes each instead of the other way around)?
  2. Is it possible to reduce the problem by indexing the DB differently (adding indexes for search performance, dropping and rebuilding the existing indexes)?
  3. Would it make any difference to performance if you configure the Wiki to save content to disc rather than to the database?



I agree that this looks like a big problem, which alarms me somewhat. Especially since there seem to be other areas where performance is not great, specifically the forums and loading large pages into the Wiki.

Questions

  1. Would it make any difference if the structures were inverted (eg 600 structures with 10 nodes each instead of the other way around)?
  2. Is it possible to reduce the problem by indexing the DB differently (adding indexes for search performance, dropping and rebuilding the existing indexes)?
  3. Would it make any difference to performance if you configure the Wiki to save content to disc rather than to the database?