According to SiteMatrix we have 739 projects at the moment. There are
three master partitions for the servers: s1 for enwiki only, s2 for 19
other projects and s3 for all the rest (that's 719 projects).
My homewiki is one of those 719 projects. And I feel a bit neglected.
Replication is halted since 34 days. LuceneSearch 2.1 is active on
enwiki since October and on dewiki and some other big wikis since
December. Most other wikis have still no access to the new features.
Even the "+incategory:" feature which is active on enwiki since April
2008 is not active on most wikis as of February 2009.
It seems, we are very low at the priority list.
Marcus Buck
What is the best way to organize infobox templates for geographic
places, the one used on the French, the Polish, or the Turkish
Wikipedia? What are the most important features in use on other
languages of Wikipedia, that my language is still missing?
Are these questions of a kind that you sometimes ask yourself?
If so, where do you go to find the answers? Are we all just
copying ideas from the English Wikipedia? Or inventing our own
wheels? Has anybody collected stories of how one project learned
something useful from another one?
--
Lars Aronsson (lars(a)aronsson.se)
Aronsson Datateknik - http://aronsson.se
Hello,
I understand the need for cite, thats why it is still there :) But...
- We format Cite references list every 100th request to backend,
though it takes 8.15% backend response time (thanks parser cache,
without it Cite formatting would take 815% cluster time - though
developers should understand I'm not exactly right at this hyperbole ;-)
- When parsing articles like one of most popular today,
[[en:Rod_Blagojevich_corruption_charges]], it takes 20s to produce the
page, 17s is spent on Cite block, executing {{cite}} mostly. That
makes every editor wait for ages to get a page displayed, and due to
cache stampede after invalidation it causes considerable stress on
site (look at numbers mentioned above).
- This 8% is in real-time, which includes waiting for search,
databases, and simply CPU contention, which we end up having today.
CPU-time wise it is way higher, so can actually have 20% CPU time
impact on our application farm. Thats at least 100k$ worth of hardware
(and rising), even if new/modern one, just for citation formatting.
So, a checklist what can be done ( simple to complex )
[ ] - Simplification of {{cite}}
[ ] - Separate cache for Cite, to avoid reparsing on minor edits,
that don't involve citations. I have no idea how much this would win,
but there is theoretical chance of stripping 1% or so. ;)
[ ] - Offload some templates like {{cite}} to actual PHP extensions
(can of worms, but, oh well, can be standardized process too)
[ ] - Implement proper scripting engine like Lua for metatemplates (http://pecl.php.net/package/lua
- another can of worms, though yet again, can be managed via trusted
set of people, on top20 wikis or so).
[ ] - Frustrated operations guy adding something like ( return ""; )
in some random extension, and syncing the live hack. Obviously there
would be some "HAHA YOU THOUGHT I COULDN'T DO THIS" comments in there.
I for one can directly participate in at least two of these options. ;-)
Unfortunately, {{cite}} is the only template I can profile/account for
now, we don't have proper per-template profiling, but I wish to get
one some day. Then we'd have more "war on ..." topics ;-D
Generally, templates are major part of our parsing, and thats over 50%
of our current cluster CPU load.
As we've actually managed to hit 100% last week, something what hasn't
happened for a while, some of work has to be done here.
Of course, new hardware will help for a while, but I for one have huge
personal satisfaction saving donation money. ;-)
CHEERS!
--
Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]
Hello everyone.
As you know, MediaWiki make XTHML like below markup:
> <h2><span class="editsection">[<a ...>edit</a>]</span> <span class="mw-headline">title</span></h2>
And shared.css set editsection class:
> .editsection {
> float: right;
> margin-left: 5px;
> }
Floating editsection links work well with IE7.
But floating editsection links move to bad position with Firefox,
Safari, and GoogleChrome.
I hope that someone makes a optional way to set editsection links after
section's titles:
> <h2><span class="mw-headline">title</span> <span class="editsection">[<a ...>edit</a>]</span></h2>
I know that we can move editsection links by JavaScript like dewp and
others. But, with such trick, editsection links seem to jump after
loading page when I read huge page. I want a way without JavaScript.
Sorry for my poor English. Thank you.
----
mizusumashi