Re: RecentChanges Performance

> Am Mit, 2002-10-30 um 13.28 schrieb Brion VIBBER:
>>Those should be fixed. Any other problems?

I tweaked GlobalFunctions.php, Article.php, and SpecialMovepage.php to 
update the recentchanges database on page deletion, image upload, and 
page rename. The RC behavior on renames over existing redirect pages is 
slightly different, and may or may not be more user-friendly than the 
current behavior.

My little old PII Linux box isn't bad-ass enough for me to dare putting 
the huuuge English Wikipedia database on it, so I just did some quick 
tests with the smaller Danish and German dbs. Using the recentchanges 
table seems to be consistently a few percent faster than reading 
straight from cur and old, but not significantly so. (This may just be 
the difference in overhead between querying two tables versus one.) 
Under load and with a larger database, there may or may not be a more 
pronounced difference.

I haven't installed any of this on the live server; somebody please 
check out the updates in CVS and look 'em over to make sure nothing else 
is broken.

Erik Moeller wrote:
> There should be an INDEX on the rc_timestamp column. 

Hmm... I'm not sure how to go about doing this. EXPLAIN already 
indicates that it's using rc_timestamp as the key, and creating an index 
vai CREATE INDEX or ALTER TABLE ADD INDEX doesn't seem to change 
anything except to add more to the list of 'possible keys'.

Re: RecentChanges Performance

Am Fre, 2002-11-01 um 15.11 schrieb Brion VIBBER:

> My little old PII Linux box isn't bad-ass enough for me to dare putting 
> the huuuge English Wikipedia database on it, so I just did some quick 
> tests with the smaller Danish and German dbs. Using the recentchanges 
> table seems to be consistently a few percent faster than reading 
> straight from cur and old, but not significantly so. (This may just be 
> the difference in overhead between querying two tables versus one.) 
> Under load and with a larger database, there may or may not be a more 
> pronounced difference.

I'll try this with the full DB on Monday, I can't do it immediately
because I have to build the RC table first, which will probably take a
while.

> Erik Moeller wrote:
> > There should be an INDEX on the rc_timestamp column. 

This is not done in the default table build, but the index is created in
the recentchanges build script. Since I haven't run that yet, my table
still lacks the index. Sorry about the confusion.

> However it's also teling me "Using filesort", which I get the impression 
> is a bad thing.

The MySQL manual has a page on this:
http://www.mysql.com/doc/en/ORDER_BY_optimisation.html
I don't see how any of the conditions they list for when the index
cannot be used to resolve ORDER BY is true in our query, though. In any
case, my guess is that this doesn't significantly affect performance as

netscape?

Hallo, seit gestern sehe ich wikipedia nicht mehr unter netscape.

Es erscheint:
----
"Warning: Too many connections in
/usr/local/apache/htdocs-de/w/DatabaseFunctions.php on line 19
Konnte keine Verbindung zur Datenbank auf 127.0.0.1 herstellen

Too many connections

If this error persists after reloading and clearing your browser cache,
please notify the Wikipedia developers."
----
Wann ist das Betrachten unter netscape wieder möglich?

Grüße von
Wolfram

Re: wikipedia.sourceforge.net

Works for me.

On Sun, 27 Oct 2002 18:56:51 -0800 (PST)
Axel Boldt <axelboldt@...> wrote:

> Has the page http://wikipedia.sourceforge.net been removed? I
> can't get there anymore. Formerly, this was a handy page
> containing an introduction to the Wikipedia software and several
> links, much more digestable than the disaster that is
> http://sourceforge.net/projects/wikipedia/
> 
> Axel
> 
> P.S. See
> http://216.239.53.100/search?q=cache:nk3YWmXcUg0C:wikipedia.sourceforge.net/+&hl=en&ie=UTF-8
> for Google's cache of the page.
> 
> __________________________________________________
> Do you Yahoo!?
> Y! Web Hosting - Let the expert host your web site
> http://webhosting.yahoo.com/
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@...
> http://www.wikipedia.org/mailman/listinfo/wikitech-l

--
Michael Brutsch
wikipedia@...
(972) 240-7094

Re: wikipedia.sourceforge.net

Axel Boldt wrote:
> Has the page http://wikipedia.sourceforge.net been removed? I can't get
> there anymore.

Either SF was down when you looked or it's just you.

 > Formerly, this was a handy page containing an
> introduction to the Wikipedia software and several links,

Still is. I've just gone in and updated some of the links while I was at it.

-- brion vibber (brion  <at>  pobox.com)

Re: netscape?

At 2002-11-01 08:51 +0100, Wolfram Steinacker wrote:
>Hallo, seit gestern sehe ich wikipedia nicht mehr unter netscape.
>
>Es erscheint:
>----
>"Warning: Too many connections in
>/usr/local/apache/htdocs-de/w/DatabaseFunctions.php on line 19
>Konnte keine Verbindung zur Datenbank auf 127.0.0.1 herstellen
>
>Too many connections
>
>If this error persists after reloading and clearing your browser cache,
>please notify the Wikipedia developers."
>----
>Wann ist das Betrachten unter netscape wieder möglich?

It has nothing to do with Netscape. The PHP script
running on the Wikipedia server couldn't connect
to the MySQL database server on that same server
because there were already too many scripts
connected to the database server.

Try again later when it's less busy in the USA.

Greetings,
Jaap

Dedicated editor for Wikipedia

Hello all,

Please read about this idea and comment on Talk page.

http://meta.wikipedia.org/wiki/Dedicated_Wikipedia_editor

Regards,
Kpjas.
--

-- 
Wikipedia - The Free Online Encyclopedia

Lag

I've been getting lag for about the past hour
that seems to be especially pronounced when saving articles.
Otherwise, it's slower than usual but still tolerable.
Saving, however, takes half a dozen minutes.

-- Toby

Automatic &#codes; to UTF8 conversion patch

Patch for Polish Wikipedia.

--- convertWiki2SQL.php.orig	2002-09-19 07:48:35.000000000 +0200
+++ convertWiki2SQL.php	2002-11-03 18:09:45.000000000 +0100
 <at>  <at>  -66,6 +66,23  <at>  <at> 
 if ( $wikiLanguage == "pl" ) {
 $wikiTalk = "Dyskusja" ;
 $fieldSeparator = "\xff";
+
+function num_to_utf8($num)
+{
+    if ($num[0][2] == 'x')
+	$i = hexdec($num[1]);
+    else
+	$i = (int)$num[1];
+    if ($i > 0 && $i < 0x7f)
+	return sprintf ("%c", $i);
+    else if ($i > 0x80 && $i < 0x7ff)
+	return sprintf ("%c%c", 0xC0 | (($i>>6) & 0x1f), 0x80 | ($i & 0x3f));
+    else if ($i > 0x800 && $i < 0xffff)
+	return sprintf ("%c%c%c", 0xE0 | (($i>>12) & 0xf), 0x80 | (($i>>6) & 0x3f), 0x80 | ($i & 0x3f));
+    else
+	return $num[0];
+}
+
 function RecodeCharsetPl ( $text ) {
 	# Convert iso8859-2 to UTF-8
 	# In a happy world, we could use iconv for this
 <at>  <at>  -85,7 +102,10  <at>  <at> 

mysql issues

There are 4 issues standing between polish wikipedia and phase 3
software.

One is automatic conversion of &#codes; are requires just a small
patch, which has been sent by me already.

Second is support for H1 (don't say that it is reserved for page
titles, CSS already treats H1 and H1.pagetitle different).

Two others are MySQL issues:
* MySQL doesn't search UTF-8 right.
* Wikipedia should be mirrorable and MySQL database dumps are not
  really convenient way.

Afair MySQL 4.1 is supposed to fix the first, and there is some
patch already that fixes that, so could you investigate that stuff ?

Mirroring by downloading dumps is very inconvenient,
making nightly patches of dump file available is bare minimum.
But in longer term some better solution should be developed.

Anyway, I'm for setting up final setup instalation as soon as
&#code; and H1 issue is fixed. MySQL issues may be hard to fix
and nothing really critical would happen if they were fixed a few
weeks later.