Hi John,
1) Splitting the tables to another database: this can be done. But note that when I compute the coloring, I need access also to the standard tables (e.g. to read the revision text to analyze). Do you think this is high priority for you? We can certainly done it in, I guess, a couple of hours of coding.
2) Splitting the computation altogether to another server. Let me consider what "computation" is. There are three kinds of computation.
a) The computation to "catch up with the past" i.e. color the existing revisions of a wiki. This is by far the heaviest load. This can (and I argue should) be done on a separate machine provided of course the machine has access to the db(s). I can add some way of throttling down the computation, so that the db access does not become too much.
b) The computation to analyze an edit. This is proportional to the n. of edits, not hits, so unless you get at least 1 edit / second, you don't need to worry.
c) The computation to serve a trust-colored page. This is a bit difficult to split to another server, as this is done via php hooks that are supposed to run on the same machine. The coloring is performed by reading a different version of a page (from a different db table), and doing a bit of html processing to it. I don't think the load is much larger than serving a normal page; we need some testing.
So I propose that I add some way of avoiding the db being accessed too often while "catching up with the past". Let me know if I should separate the wikitrust tables in a different db. Would you think these two measures are enough?
Luca
2008/8/27 John Erling Blad john.erling.blad@jeb.no
Anyhow, it seems like there are some interest at no.wikipedia.org, but we do have a traffic load even if its not one of the main wikis. Its about 10-100 000 hits each hour.
Is it possible to split out the tables to another database? That way it isn't going to impact the overall performance. Also, is it possible to completly split out the preprocessing?
John
mike.lifeguard skrev:
Well, en.labs would be best, as it is a site for testing :D But yes, English Wikibooks is a good candidate once we have explored the issue of long-untouched pages (ie the trust should be recalculated, I think)
Mike
*From:* wikiquality-l-bounces@lists.wikimedia.org [mailto:wikiquality-l-bounces@lists.wikimedia.org] *On Behalf Of *Luca de Alfaro *Sent:* August 26, 2008 10:59 PM *To:* Wikimedia Quality Discussions *Subject:* Re: [Wikiquality-l] WikiTrust v2 released: reputation andtrustforyour wiki in real-time!
Yes, I fully agree. We should start on a small project where people are interested. We can consider the bigger wikis later, once we are confident that we like it and it works the way we want. I was citing Enwiki just to discuss potential performance. Ian and I can help with advice etc anyone who wants to try this out. Luca
On Tue, Aug 26, 2008 at 6:54 PM, Andrew Whitworth <wknight8111@gmail.com mailto:wknight8111@gmail.com> wrote:
On Tue, Aug 26, 2008 at 9:42 PM, mike.lifeguard
<mike.lifeguard@gmail.com mailto:mike.lifeguard@gmail.com> wrote:
even on the English Wikipedia (5 edits / second at most?) a single CPU would suffice
But why start so large? Pick a smaller test wiki first like, say, en.wikibooks? We can throw that into the queue of things we want installed down at WB.
--Andrew Whitworth
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org mailto:Wikiquality-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikiquality-l
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikiquality-l
Wikiquality-l mailing list Wikiquality-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikiquality-l