-
|
Possible options:
PS: One more question: will it still be faster if a page have so many transclusions like Wikipedia? I'm also trying to write a wiki software called LuaWiki. So I want to learn something from this project. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
(enabled and moved this to discussions, as it fits there better) Poeh, difficult question to answer. First, let me hook into two things you mention:
Not sure that really matters in terms of speed. Sure, TrueWiki (or more specifically, wikitextparser) implements a subset of the mediawiki syntax, but it is pretty complete.
Having blobs of text on disk (not as much git, but just local files) surely helps. A database trip mostly is more expensive. Especially as kernel caching makes repeated access to the same file very very fast. A database cannot compete with that. But for your real question:
I think it is a bit of the wrong question. The goal of TrueWiki has never been to "outperform" MediaWiki in any way. The goal was to make a wiki that is easy to maintain, and does cost a lot of money a month just to host a mostly static database. What sets TrueWiki much more apart from MediaWiki, is that is has a strong opinion on how it should be used. MediaWiki, with all its extensions, allows you to do what-ever you want. TrueWiki bakes in language-support, doesn't allow for custom namespaces, etc etc. And sure, in terms of performance these kind of things help. But that was never the goal. Making sure it is easy to maintain, and easy for anyone to understand, that was much more the goal. Also important to note, that TrueWiki doesn't scale to sizes like Wikipedia (it could be made to, but it doesn't). In its fastest form, TrueWiki caches every HTML page to disk, so it is served really quick on second request (think < 1ms render times). This works well for the most common wikis, but of course doesn't work in the scale of Wikipedia. In the end, it is to every one its own. For OpenTTD we were looking for a cheap (hosting-cost-wise) solution .. and needing a pretty beefy database to run a mostly static wiki, doesn't fit that bill. So TrueWiki fills that hole .. it is cheap to host (like, really cheap), it does everything a wiki should be doing (but nothing more; no extensions etc), and is easy to maintain. So sorry for dodging your question a bit here; if you have any specific questions, feel free to ask, but in the end, performance was just a nice extra. With that I try to say: I think it is mostly because of a difference of approach in how to make a wiki. Strongly opinionated (TrueWiki) vs "everything should be possible" (MediaWiki).
Both TrueWiki and MediaWiki scale, from what I remember, pretty much the same. So yeah, the difference will remain.
Nice, good luck :) Always fun to write your own software :) I think the README of TrueWiki explains most, why it came to be, what hole it tries to fill .. but feel free to ask any other questions you have. I will try my best to answer them! |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for this thorough answer. TrueWiki is a nice piece. Compared to mediawiki, TrueWiki will be very easy to maintain, and since it uses a file system for storage and is managed with git, it can save some money, especially when deployed in the cloud. These are also part of goals I want to achieve. |
Beta Was this translation helpful? Give feedback.
(enabled and moved this to discussions, as it fits there better)
Poeh, difficult question to answer. First, let me hook into two things you mention:
Not sure that really matters in terms of speed. Sure, TrueWiki (or more specifically, wikitextparser) implements a subset of the mediawiki syntax, but it is pretty complete.
Having blobs of text on disk (not as much git, but just local files) surely helps. A database trip mostly is more expensive. Especially as kernel caching makes repeated access to the same file very very fast. A database…