Ulrich Fuchs wrote:
>>Why can't we simply have a Wiki-editable server down message that will
>>be used automatically?
By definition we can't since when the wiki is down it can't access the wiki.
>> In particular, it should be a different one on
>>each different language Wikipedia. :-p
That we've already got. (Devs: please use outage.php and declareOutage()
rather than hard-coding $wgSiteNotice.)
> Yes. PLEASE. And PLEASE: Would the developers please announce on THIS LIST:
It took me a while to get this information out of people but here we go:
> * When the Wiki will go down
18:00 UTC tomorrow (June 11).
> * Why the Wiki will go down
To reboot Zwinger with an updated kernel which will fix the disk driver.
This should improve performance; as the main file (not database) server
the sluggish disk is a bottleneck.
> * And how long the outage will be.
Estimated at a half hour.
> That isn't so difficult, is it?
>
> Please give us at least 15 Minutes to change the mentioned server down message
> accordingly, so that people can save their work.
In theory, we've committed to always giving 24 hours notice prior to any
planned maintenance downtime.
-- brion vibber (brion @ pobox.com)
Can somebody please look into this?
This was adaquately described by Timwi on this list and I include the
final message from the discussion. I certainly tried to correct the
problem with
reediting and correcting the offending messages but alas!
This behaviour appears only in the new monobook interface, it works
correctly
if the user switches to other styles.
Please help.
Thanx
ank
> Brion Vibber wrote:
>
>> Timwi wrote:
>>
>>> On second inspection, it definitely does *not* look fine!
>>> http://meta.wikipedia.org/upload/3/38/Greek_problem_screenshot.png
>>> This seems to be a problem with the software. The messages in the
>>> MediaWiki namespace of [[el:]] are correct.
>>>
>>> Someone seriously needs to fix that, quickly.
>>
>>
>> Use the letter "i" instead of the number "1" in "π" and "φ".
>
>
> Brion, if you read my message, you will see that I said "The messages
> in the MediaWiki namespace of [[el:]] are correct." They are using
> neither "π" nor "&p1;", but the correct UTF-8 character for Greek Pi.
>
> Please fix this. (When Wikipedia is back up ...)
>
> Thanks,
> Timwi
--
Andreas Kasenides
e-mail: Andreas.Kasenides_at_cs.ucy.ac.cy
<mailto:Andreas.Kasenides%20at%20cs.ucy.ac.cy>
(replace the _at_ above with @)
Hi all,
I've recently installed MediaWiki 1.3.0beta2 (off the CVS tip) on a
Linux box and, while it works really nicely -- lots of kudos to all tje
developers out there -- I want to make sure that my server is configured
for best performance; right now response time is not super fast,
although not terrible either.
I'm running the site on a "virtual-server" 2GB 2-proc machine running
Redhat 9. I have Apache 2.0.49, PHP 4.3.6, MySQL 4.0 stable.
I installed all these myself and am using pretty much whatever the
default configurations are. I wonder if in particular for MySQL (and
perhaps Apache) I may have a sub-optimal configuration.
So I'm basically looking for hints on what configuration values people
have used for MySQL (memory, buffer sizes, cache sizes, etc), PHP (mysql
persistent connections or not?), Apache (threading module type, memory,
caveats, etc etc) that have shown good improvements.
I did just see the post on Apache settings not making much of a
difference, but maybe MySQL settings might. I don't have that many pages
or users on this new wiki (SeattleWiki.org) yet, but I'm hoping that
will change soon, and I'm hoping to be ready for it :)
Incidentally I couldn't find a page with this info on meta.wikipedia but
maybe I didn't look hard enough. I can definitely add any useful replies
to a new "performance settings" page.
Thanks in advance,
Matias
I've just committed some major changes:
* accesskeys and tooltips moved to js, needs to be customized/localized
at MediaWiki:Monobook.js. Saves many calls to wfMsg, reduces page size,
shows access key prefix depending on browser/os. Easy to customize by
changing the ta array.
* skinphptal underline and justification wired up to produce generated
css
* MediaWiki:Skin.css used for anons as well
* addcss call removed from header
* separate js var file included that holds things like the stylepath and
the tooltip/accesskey array
* rtl css included from generated css
Translators:
Many translated accesskey-XY and tooltip-XY messages need to be moved to
the Monobook.js array, they are now deprecated. The remaining ones might
follow soon.
I also changed the wording and key of the 'clear your cache' message as
it's now also displayed above the prefs as well. A new string is
qbsettingsnote.
Gabriel Wicke
I initially discarded this as spam (HTML mail, request for
"partnership", first paragraph links to a web site) but on second look
it looks legit. Sorry!
-------------
Subject: Urgent : Demande de Partenariat / Urgent: Ask Partnership
From: "responsable.ekipage" <responsable.ekipage at online.fr>
Date: Wed, 9 Jun 2004 16:22:39 +0200
To: <wikitech-l at wikipedia.org>
Monsieur,
Ne sachant trop à qui m'adresser, je me permets de vous écrire, espérant
qu'il vous sera possible de transmettre mon courrier à la personne
concernée par ma requête.
Je développe un site ludo-éducatif pour enfants : www.ekipage.net non
commercial et totalement gratuit.
Ce site comporte également un espace dédié aux enseignants (représentant
90% des inscrits) et aux parents.
Je souhaiterais solliciter l'autorisation d'utiliser votre encyclopédie
selon plusieurs modalités éventuelles (et que vous définirez), dans la
perspective de permettre aux enseignants (notamment) d'accéder à votre
encyclopédie libre pour une utilisation scolaire par exemple.
* Soit en intégrant un moteur de recherche dans Ekipage, lequel
moteur utilisant le Contenu de Wikipédia (s'il vous est possible de me
fournir le code htlm)
* Soit en me permettant de faire ouvrir votre site dans une frame
de mon propre site,
* Soit en téléchargeant le contenu de Wikipédia :
http://download.wikipedia.org/ (lequel serait directement utilisable
sur mon site).
Il va de soit, que je ferais tous les liens et mentions que vous
souhaiterez (en référence à Wikipédia) et peut bien évidemment insérer
votre logo.
Le projet : Wiktionary (http://fr.wiktionary.org) : un dictionnaire et
thésaurus, m'intéresse également dans le même cadre. En outre, il
apparaît que les enseignants venant sur mon site, pourraient être
intéressés pour apporter leur contribution à ce projet.
Un grand merci par avance de votre réponse,
Anne REQUIER (France)
Dear Sir,
Too not knowing with which to address to me, I allow myself to write to
you, hoping that it will be possible for you to transmit my mail to the
person concerned with my request. I develop an ludo-educational site
for children: www.ekipage.net noncommercial and completely free.
This site also comprises a space dedicated to the teachers (accounting
for 90% of the registered voters) and to the parents. I would wish to
request the authorization to use your encyclopaedia according to several
possible methods (and that you will define), with a view to to allow the
teachers (in particular) to reach your free encyclopaedia for a school
use for example.
* Either by integrating an engine of research in Ekipage, which
driving using the Contents of Wikipédia (if it is possible for you to
provide me the code htlm)
* Or while allowing me to make open your site in a frame of my own
site,
* Or by downloading the contents of Wikipédia:
http://download.wikipedia.org/ (which would be directly usable on my site).
It goes from is, that I would establish all the links and mentions
which you will wish (in reference to Wikipédia) and can obviously insert
your logo.
The project: Wiktionary (http://fr.wiktionary.org): a dictionary and
thesaurus, also interest me within the same framework. Moreover, it
appears that the teachers coming on my site, could be interested to
contribute their share to this project.
Large a mercy by advance of your answer, Anne REQUIER (France)
N'oubliez pas de visiter notre site ludo-éducatif pour
enfants du primaire et du collège à l'adresse suivante www.ekipage.net !
Hi all,
I want to make a template page where, if I use it
without arguments, the parameter {{{1}}} has the value
{{PAGENAME}}, but if I do use an argument, the
parameter
{{{1}}} has the value with which I'm calling.
Is that possible?
Sorry if this is not the proper list.
Also sorry for even asking the question, but after
close to an hour looking through the documentation in
meta and en, I still don't know if this is possible.
AstroNomer
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
Hi all,
sorry if this has been brought up before (I'm not reading wikitech-l on a
regular basis), but I just got an idea for reducing the server load at
Wikipedia without messing around with distributed databases and the like:
Why not distribute static images and media files for starters?
http://de.wikipedia.org/upload/9/9a/WikiReader_Internet.pdf alone will be
responsible for more than 5 GB of transfer volume this month (a guess based
on my experience with http://tkarcher.gmxhome.de/WikiReader_Schweden.pdf ).
With more and more images and large media files on the rise, we could
noticeably reduce the server load by distributing these files.
How? Well, first we'd need some (5 to 10?) mirrors willing to sync their
data on a daily basis. Once these servers are up and running, we could
implement a simple, PHP-driven load balancing by changing the image (and
media file) source locations dynamically. (Script driven as opposed to
server driven, because we'd have to check whether the file was added within
the last 24 hours. You wouldn't want to wait for your newly added image to
appear in your article a whole day, would you?)
What do you think about it?
Thomas
EasyTimeline by Erik Zachte is an extension for creating graphical
timelines with clickable links. WikiHiero by Guillaume 'Aoineko' Blanchard
is for rendering hieroglyphs. Both are now enabled on all Wikimedia wikis.
As per our earlier extension syntax vote, EasyTimeline uses the <timeline>
syntax, WikiHiero uses the <hiero> syntax.
You can read more about them here:
http://test.wikipedia.org/wiki/EasyTimelinehttp://test.wikipedia.org/wiki/WikiHiero
To my knowledge, MediaWiki is the only wiki software which supports such
functionality. It should make our wikis interesting even in the highest
academic circles.
Although EasyTimeline can generate SVG output, only PNG output is
currently supported. In the future, we hope to offer SVG as a user
preference.
Regards,
Erik
Jeronim and I spent about three hours doing some load testing on yongle
after taking it out of rotation. The idea was to see whether Apache
tweaking could effect any kind of a performance increase. Short summary:
it couldn't.
100 requests randomly sent to a sample of URLs collected from 'en' main
page produced the following numbers:
Elapsed time: 7.50 secs
Data transferred: 3137074 bytes
Response time: 0.64 secs
Transaction rate: 13.33 trans/sec
Throughput: 418276.53 bytes/sec
Concurrency: 8.51
Slow. Next step was to remove all of the Special:* and Category:* pages
from the list, since they're database-intensive. The load test now
completed in 6.21 seconds, with 16.1 trans/s. Marginal increase, but
nothing significant.
Two particular pages were then picked: [[Vietnam War]] (large) and
[[Pyrite]] (small). Running with 50 concurrent clients, 50 repetitions,
Pyrite rendered with about 21.6 trans/sec and Vietnam War with about
18.9 trans/sec. A static image file (from upload) was then tried,
yielding 1785 trans/s.
Two different sets of Apache settings for Max/Min SpareServers,
StartServers, MaxClients and MaxRequestsPerChild were tried, but the
resulting performance numbers didn't seem different in any way that
would hold up to statistical significance. Bottom line: Apache doesn't
even get close to being a bottleneck.
A survey of the apache machines showed about 5-19 requests/sec being
processed on them. The boxes had little free ram lying around, but
generally weren't swapping. However, if these numbers are any good
indication, here's some inference, which should be taken as educated
guessing only:
- PHP/Mediawiki are slow. A good start for anyone willing to tackle this
will be to look at
http://meta.wikipedia.org/wiki/Profiling/Live_aggregate_20040606
- The current Wikipedia setup won't scale too much, but things will
improve once the servers we've been having problems with become
operational. From there on, we'll likely be able to deal with growth by
just acquiring new apaches and putting them into the farm.
- Static files are by no means a bottleneck, and should not be a
priority for distribution in the near future.
Cheers,
Ivan.
