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>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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