jidanni | 1 Aug 2010 04:04
Favicon
Gravatar

Re: Caching, was: Re: wikipedia is one of the slower sites on the web

OK man, you've got me committed to the spirit of using as many default
settings as I can stand.

P> math preference, date format, auto-number headings, user language, image
P> thumbnail size.

Which brings up the question "Which of (these and) the rest of my
settings are not the default?"

Any easy way (for the average non-insider Junior User, not me with the
source code) to tell in one click?

"Can I be allowed to examine a list and pick and choose which ones I
want to restore the defaults of?"

Or must he hit the Slaughterhouse Button
https://bugzilla.wikimedia.org/show_bug.cgi?id=17188
Amir E. Aharoni | 1 Aug 2010 10:49
Picon
Picon
Gravatar

Math - Recommended for modern browsers

This is a follow up to "wikipedia is one of the slower sites on the web".

In Math preferences what does the "Recommended for modern browsers"
option actually mean? I like to think of myself as someone who uses
modern browsers, so i select it on every MediaWiki site in which i
open an account, but i never seriously thought about its meaning
except fantasizing that it uses MathML, which it probably doesn't.

I also think that trying to select "MathML if possible" didn't change
anything for me (Firefox 3.6.8 on XP).

There's a question similar to mine at
http://meta.wikimedia.org/wiki/Help_talk:Preferences since 2006.

--

-- 
אָמִיר אֱלִישָׁע אַהֲרוֹנִי
Amir Elisha Aharoni

http://aharoni.wordpress.com

"We're living in pieces,
 I want to live in peace." - T. Moore

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Aryeh Gregor | 1 Aug 2010 20:14
Picon

Re: MediaWiki version statistics

On Fri, Jul 30, 2010 at 10:28 PM, K. Peachey <p858snake <at> yahoo.com.au> wrote:
>  I would highly unrecommended having the update feature in there, we
> already highly recommend against running as a db user with certain
> admins rights amongst other things, this feature will probably end up
> breaking more installs then updating (and yes I know wordpress has it,
> and I know how many times i've had to fix their botch updates), and
> not all installs would have the required modules that it needs
> (cURL/wGet comes to mind on IIS setups which some people use). Nor
> should we be assigning the update right or giving messages to the
> admin group by default, since most people that are admins are non
> technical and will just click any bright button that has messages
> along the lines of "omg update me now" without thinking if it will
> break something (Perhaps we should un-deprecate the developer
> usergroup for this).

If I'm interpreting this right, you're saying that upgrades can break
stuff, so people should stick to versions with known security flaws.
This is a defensible position in practice, but it doesn't justify
making upgrades unnecessarily hard.  It would be a good thing if
typical admins could easily upgrade, without needing FTP access and so
forth.  If they choose not to, that's their choice, but if they want
to upgrade, they should be able to do so easily.

On Fri, Jul 30, 2010 at 10:55 PM, K. Peachey <p858snake <at> yahoo.com.au> wrote:
> You would also need to be vigilant and make sure people don't
> vandalize the information, For example if a spam version change got
> entered and broke someones installed.

Any kind of auto-update mechanism should be hardcoded to retrieve only
from a specific Wikimedia URL and only over HTTPS, and the contents of
(Continue reading)

Aryeh Gregor | 1 Aug 2010 20:34
Picon

Re: wikipedia is one of the slower sites on the web

On Fri, Jul 30, 2010 at 1:32 PM, John Vandenberg <jayvdb <at> gmail.com> wrote:
> So you're telling my theoretical logged-in-reader to use default
> prefs, or log out, when the reason they are a logged-in-reader is so
> they can control their preferences..!

Yep.  You want features, you often pay a performance penalty.  In this
case the performance penalty should be reducible, or at least clearly
marked, but that's a general rule anyway.

> Surely there are a few common 'preference sets' which large numbers of
> readers use?

Changing any parser-related preference will kill page load times.

> There are plenty of pages which change more than once per minute,

No pages change once per minute on average.  That would be 1440 edits
per day, or more than 500,000 per year.  Only one page on enwiki
(WP:AIAV) has more than 500,000 edits *total*, let alone per year.
There were only 18 edits to WP:ANI between 17:00 and 18:00 today, just
for example, which is less than one edit every three minutes.  There
are some times when a particular page changes many times in a minute
-- like when a major event occurs and everyone rushes to update an
article -- but these are rare and don't last long.

You also seem to be missing how many different possible parser cache
keys there are.  It's not like there are only five or ten possible
versions.  As I said before -- if you change your parser-related
settings around a bunch, you will probably rarely or never hit parser
cache except when you yourself viewed the page since it last changed.
(Continue reading)

Platonides | 1 Aug 2010 20:38
Picon

Re: Math - Recommended for modern browsers

Amir E. Aharoni wrote:
> This is a follow up to "wikipedia is one of the slower sites on the web".
> 
> In Math preferences what does the "Recommended for modern browsers"
> option actually mean? I like to think of myself as someone who uses
> modern browsers, so i select it on every MediaWiki site in which i
> open an account, but i never seriously thought about its meaning
> except fantasizing that it uses MathML, which it probably doesn't.
> 
> I also think that trying to select "MathML if possible" didn't change
> anything for me (Firefox 3.6.8 on XP).
> 
> There's a question similar to mine at
> http://meta.wikimedia.org/wiki/Help_talk:Preferences since 2006.

The software used to render the math (texvc), catalogues the html it
outputs as conservative, moderate or liberal.

"Recommended for modern browsers" means "I can show any html but the
liberal one". That's also the option taken if you requested MathML but
it was unable to generate MathML for that equation.

"HTML if possible" means that it accepts even "liberal" HTML (something
that should be able to do today's modern browsers...). Again, if there's
no html equivalence, you get an image.

"HTML if very simple" means that it only accepts "conservarive" HTML.

The other two options "Always render PNG" and "Leave it as TeX" are
self-explicative.
(Continue reading)

David Gerard | 1 Aug 2010 21:40
Picon
Gravatar

Re: MediaWiki version statistics

On 1 August 2010 19:14, Aryeh Gregor <Simetrical+wikilist <at> gmail.com> wrote:

> If I'm interpreting this right, you're saying that upgrades can break
> stuff, so people should stick to versions with known security flaws.
> This is a defensible position in practice, but it doesn't justify
> making upgrades unnecessarily hard.

I assume this is based on WordPress, where this happening was a bit of
a problem for a while. These days it works pretty flawlessly. (3.0.1
is just out, I should probably install it.)

>  It would be a good thing if
> typical admins could easily upgrade, without needing FTP access and so
> forth.  If they choose not to, that's their choice, but if they want
> to upgrade, they should be able to do so easily.

WordPress asks for the account's SFTP password, which I don't find
feels like an undue imposition.

Basically, such a mechanism will be compared to WordPress every step
of the way :-)

- d.

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Edward Z. Yang | 1 Aug 2010 22:04
Picon
Favicon

Re: MediaWiki version statistics

Hello Tim,

I'd like to contribute a somewhat different (although I suppose
common) perspective to this discussion.  I help run a free-for-the-community
shared webhosting service, and one of the services we have is "automatic
installation" of common web applications for people who don't know
very much about setting up or deploying applications.  Wordpress and
MediaWiki are among our most popular installations.

Since it's not reasonable to assume someone who can click a button to
setup an application has the know-how to upgrade it manually, any
installation that we autoinstall also comes with an upgrade promise:
when new versions of the application come out, we reserve the right to
automatically upgrade the application for you.  (Since we allow users
to patch their installs, there are some, ah, technical difficulties associated
with this.)

We've noticed several things:

    - When Wordpress 3.0 came out, we received several support tickets
      asking us when we would be pushing an upgrade, and asked us if
      anything bad would happen if they went ahead and upgraded their
      install themselves.  We have /never/ had this happen for MediaWiki.

    - Our spread of versions is quite interesting:

wordpress            649 installs
    2.0.2      *       5  +
    2.0.4              7  +
    2.0.11             4  +
(Continue reading)

Platonides | 1 Aug 2010 22:18
Picon

Re: wikipedia is one of the slower sites on the web

Aryeh Gregor wrote:
> Look, this is just not a useful solution, period.  It would be
> extremely ineffective.  If you extended the permitted staleness level
> so much that it would be moderately effective, it would be useless,
> because you'd be seeing hours- or days-old articles.  On the other
> hand, for a comparable amount of effort you could implement a solution
> that actually is effective, like adding an extra postprocessing stage.

Yes, I have some ideas on how to improve it.

> On Fri, Jul 30, 2010 at 1:32 PM, John Vandenberg <jayvdb <at> gmail.com> wrote:
> Someone who sets their stub threshold to 357 is their own performance enemy.

In fact, setting the stub threshold to anything disables the parser
cache. You can only hit it when it is set to 0.

Aryeh, can you do some statistics about the frequency of the different
stub thresholds? Perhaps restricted to people which edited this year, to
discard unused accounts.
Roan Kattouw | 1 Aug 2010 22:43
Picon

Re: wikipedia is one of the slower sites on the web

2010/8/1 Platonides <Platonides <at> gmail.com>:
> Aryeh, can you do some statistics about the frequency of the different
> stub thresholds? Perhaps restricted to people which edited this year, to
> discard unused accounts.
>
He can't, but I can.  I ran a couple of queries and put the result at
http://www.mediawiki.org/wiki/User:Catrope/Stub_threshold

Roan Kattouw (Catrope)
Chad | 1 Aug 2010 22:46
Picon

Re: wikipedia is one of the slower sites on the web

On Sun, Aug 1, 2010 at 1:43 PM, Roan Kattouw <roan.kattouw <at> gmail.com> wrote:
> 2010/8/1 Platonides <Platonides <at> gmail.com>:
>> Aryeh, can you do some statistics about the frequency of the different
>> stub thresholds? Perhaps restricted to people which edited this year, to
>> discard unused accounts.
>>
> He can't, but I can.  I ran a couple of queries and put the result at
> http://www.mediawiki.org/wiki/User:Catrope/Stub_threshold
>

Isn't stub threshold a *reading* preference? It wouldn't be
unreasonable to assume that someone could have that
preference set and not regularly edit.

Also doesn't take into account people who haven't changed
their preferences in a long time (and thus aren't in user_props
yet)

-Chad

_______________________________________________
Wikitech-l mailing list
Wikitech-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Gmane