The LanguageSelector extension [1] can automatically set the interface language based on browser settings, which is nowadays the norm for every serious multilanguage web page. It is not used on WMF wikis, because it would interfere with caching. The strategic planning wiki [2] has, however, relatively low traffic, and probably much higher logged-in to anon ratio than the rest of the sites. Any chance LanguageSelector (or something equivalent, if it exists) could be used there?
[1] http://www.mediawiki.org/wiki/Extension:LanguageSelector [2] http://strategy.wikimedia.org/wiki/Main_Page
On 9/9/09 6:28 AM, Tisza Gergő wrote:
The LanguageSelector extension [1] can automatically set the interface language based on browser settings, which is nowadays the norm for every serious multilanguage web page. It is not used on WMF wikis, because it would interfere with caching. The strategic planning wiki [2] has, however, relatively low traffic, and probably much higher logged-in to anon ratio than the rest of the sites. Any chance LanguageSelector (or something equivalent, if it exists) could be used there?
Not sure; it ties in with the rest of our infrastructure so it's got the same caching layers in front of it...
We've been hashing around the idea of allowing Accept-Language through for eg Chinese variant selection, but the main problem with doing it well is that we need some pre-processing at the cache level to keep the cache locality relatively non-insane. :) The set of possible Accept-Language headers is open-ended and huge, so we can't just add a Vary: without greatly increasing the amount of cache space that'll be used by that site.
That would be easier to do with Varnish (which has a much cleaner plug-in system) than with Squid, but we're nowhere near a Varnish deployment yet.
Mark, how hard would it be in theory to swap some settings around to make one of our low-traffic sites take different caching characteristics, like leaving just strategy.wikimedia.org with either a Vary: Accept-Language or just having it not cache as much?
-- brion
Mark, how hard would it be in theory to swap some settings around to make one of our low-traffic sites take different caching characteristics, like leaving just strategy.wikimedia.org with either a Vary: Accept-Language or just having it not cache as much?
thats not squid setting, one can just send proper cache-control headers.
on the other hand, can we please avoid having these kinds of "special cases" all over - it is pain to do performance management with current stuff already.
Cheers, Domas
On 9/10/09 9:04 AM, Domas Mituzas wrote:
Mark, how hard would it be in theory to swap some settings around to make one of our low-traffic sites take different caching characteristics, like leaving just strategy.wikimedia.org with either a Vary: Accept-Language or just having it not cache as much?
thats not squid setting, one can just send proper cache-control headers.
As long as Squid isn't overwriting those headers, as we do for Cache-Control. :)
on the other hand, can we please avoid having these kinds of "special cases" all over - it is pain to do performance management with current stuff already.
Yeah, special cases suck. :(
-- brion
As long as Squid isn't overwriting those headers, as we do for Cache-Control. :)
Squid is overriding at the edge all text content CC headers into:
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
MediaWiki Cache-Control is used internally though. This allows us full control on lifetime of object with application only, no need to tweak any squid stuff.
Yeah, special cases suck. :(
Especially when they're just eye-candy for english-language site.
Domas
2009/9/10 Domas Mituzas midom.lists@gmail.com:
Squid is overriding at the edge all text content CC headers into:
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
MediaWiki Cache-Control is used internally though. This allows us full control on lifetime of object with application only, no need to tweak any squid stuff.
Speaking of which, could we exempt api.php from this? It sets sane Cache-Control: headers on its own, which should not be overwritten. See also https://bugzilla.wikimedia.org/show_bug.cgi?id=14402#c11 and downwards.
Roan Kattouw (Catrope)
Hi!
Speaking of which, could we exempt api.php from this?
We could, we may, I just did it, though...
can anyone explain the C-C header logic to me? For now I see it is mostly:
Cache-Control: s-maxage=0, must-revalidate, max-age=0 Expires: Thu, 01 Jan 1970 00:00:01 GMT
Also, opensearch has this: Cache-Control: s-maxage=1200, must-revalidate, max-age=1200
what is the 'must-revalidate' doing here? why is there no 'public', etc?
"It sets sane Cache-Control: headers on its own," - does it? :)
Domas
2009/9/11 Domas Mituzas midom.lists@gmail.com:
Hi!
Speaking of which, could we exempt api.php from this?
We could, we may, I just did it, though...
Yay, thanks!
can anyone explain the C-C header logic to me? For now I see it is mostly:
Cache-Control: s-maxage=0, must-revalidate, max-age=0 Expires: Thu, 01 Jan 1970 00:00:01 GMT
Also, opensearch has this: Cache-Control: s-maxage=1200, must-revalidate, max-age=1200
what is the 'must-revalidate' doing here? why is there no 'public', etc?
"It sets sane Cache-Control: headers on its own," - does it? :)
I guess we need public instead of must-revalidate in some places. Someone asked if we shouldn't add must-revalidate conditionally [1], but when I asked on what condition (hey, I don't know all that much about C-C headers, I'm just the code monkey here :P ) I got no response. If someone tells me what the correct behavior is, I'll happily implement it.
Roan Kattouw (Catrope)
On Thu, Sep 10, 2009 at 11:48 AM, Brion Vibber brion@wikimedia.org wrote:
Mark, how hard would it be in theory to swap some settings around to make one of our low-traffic sites take different caching characteristics, like leaving just strategy.wikimedia.org with either a Vary: Accept-Language or just having it not cache as much?
Well, I *think* we requested this on foundationwiki a few years ago... but we got turned down because of the squid-setup issue. (I can't find a bug though.) If you get it on strategywiki, can we get it there too? :-)
On 9/10/09 2:40 PM, Casey Brown wrote:
On Thu, Sep 10, 2009 at 11:48 AM, Brion Vibberbrion@wikimedia.org wrote:
Mark, how hard would it be in theory to swap some settings around to make one of our low-traffic sites take different caching characteristics, like leaving just strategy.wikimedia.org with either a Vary: Accept-Language or just having it not cache as much?
Well, I *think* we requested this on foundationwiki a few years ago... but we got turned down because of the squid-setup issue. (I can't find a bug though.) If you get it on strategywiki, can we get it there too? :-)
We push foundationwiki pretty hard sometimes (such as at fundraiser time)... we'd want to make sure we can actually handle it efficiently before considering that.
-- brion
On Thu, Sep 10, 2009 at 3:45 PM, Brion Vibber brion@wikimedia.org wrote:
On 9/10/09 2:40 PM, Casey Brown wrote:
On Thu, Sep 10, 2009 at 11:48 AM, Brion Vibberbrion@wikimedia.org
wrote:
Mark, how hard would it be in theory to swap some settings around to make one of our low-traffic sites take different caching characteristics, like leaving just strategy.wikimedia.org with either a Vary: Accept-Language or just having it not cache as much?
Well, I *think* we requested this on foundationwiki a few years ago... but we got turned down because of the squid-setup issue. (I can't find a bug though.) If you get it on strategywiki, can we get it there too? :-)
We push foundationwiki pretty hard sometimes (such as at fundraiser time)... we'd want to make sure we can actually handle it efficiently before considering that.
-- brion
apachebench?
On Thu, Sep 10, 2009 at 4:22 PM, Domas Mituzas midom.lists@gmail.comwrote:
apachebench?
How does apachebench help with efficiency? Please consider thinking before posting on this mailing list!
Domas
apachebench does help with efficiency. It is inefficient (not to mention irresponsible) to wait to benchmark your code until you have a throng of users actually relying on it. Apachebench will allow you to set the header needed to trigger the language content shift in mediawiki while simultaneously hammering the server with such requests. Please think before being hypercritical of reasonable suggestions.
Hello!
apachebench does help with efficiency. It is inefficient (not to mention irresponsible) to wait to benchmark your code until you have a throng of users actually relying on it.
It isn't matter of benchmarking, it is matter of relative resource costs, compared with other projects, and no way you'd get the answer with benchmarking tool. Do note, we have a cluster which serves thousands of other requests, so we may have capacity to serve various exceptions, but we may as well want to spend that capacity on more efficient things, like, um, wikis without eyecandies (interface language changes for english language wikis? way to go!)
Apachebench will allow you to set the header needed to trigger the language content shift in mediawiki while simultaneously hammering the server with such requests.
We already know the costs, we do profile. We have way more detailed costs than anything 'ab' can provide. We have way more capacity in our cluster than a single-threaded benchmark tool can load properly.
Domas
On Fri, Sep 11, 2009 at 1:32 PM, Domas Mituzas midom.lists@gmail.comwrote:
Hello!
apachebench does help with efficiency. It is inefficient (not to mention irresponsible) to wait to benchmark your code until you have a throng of users actually relying on it.
It isn't matter of benchmarking, it is matter of relative resource costs, compared with other projects, and no way you'd get the answer with benchmarking tool. Do note, we have a cluster which serves thousands of other requests, so we may have capacity to serve various exceptions, but we may as well want to spend that capacity on more efficient things, like, um, wikis without eyecandies (interface language changes for english language wikis? way to go!)
Apachebench will allow you to set the header needed to trigger the language content shift in mediawiki while simultaneously hammering the server with such requests.
We already know the costs, we do profile. We have way more detailed costs than anything 'ab' can provide. We have way more capacity in our cluster than a single-threaded benchmark tool can load properly.
Domas
If you know the costs so well, why is there a need to see if the foundation wiki buckles under the load during fundraiser time?
I believe you have grossly misrepresented the capabilities of apachebench, and per your message it appears that you've never used it.
Hi!
If you know the costs so well, why is there a need to see if the foundation wiki buckles under the load during fundraiser time?
does it? is it really foundation wiki, that is on our shared cluster, or is that separate donation site, which is entirely separate from the system? If you talk about latter, I don't care, I was involved only to fix embarrassing mistakes, and I don't know those costs. I do know what runs on our main cluster, though :)
I believe you have grossly misrepresented the capabilities of apachebench, and per your message it appears that you've never used it.
actually, if you checked our SAL, you'd find these entries:
• 19:14 domas: xcache was both slower and less stable (got corrupted cache within seconds, can we blame that on -O3? :)) • 18:56 domas: (xcache is configured to have ttl of 600 seconds on all php objects.. ;-) • 18:55 domas: installed php5-xcache on srv250 (manual comment in apc.ini though...)
In here, between 18:56 and 19:14 I've been doing quite a bit of 'apachebench' ;-) Just so that you knew.
Cheers, Domas
On Fri, Sep 11, 2009 at 3:21 PM, Brian Brian.Mingus@colorado.edu wrote:
apachebench does help with efficiency. It is inefficient (not to mention irresponsible) to wait to benchmark your code until you have a throng of users actually relying on it. Apachebench will allow you to set the header needed to trigger the language content shift in mediawiki while simultaneously hammering the server with such requests. Please think before being hypercritical of reasonable suggestions.
Number one: suggesting "use apachebench" is not really helpful, because anyone who's even the slightest bit competent knows about it. Although I'm sure you were only trying to be helpful, giving very basic suggestions can be taken to imply that you have a very low opinion of your audience's technical knowledge, and tends to offend people.
Number two: no, it's not inefficient to profile instead of benchmark. Benchmarking is artificial and will not trigger real usage patterns. It's inefficient to waste effort tracking down and fixing performance problems that might not arise in the real world, and at the same time a real-life usage pattern could very easily trigger something your benchmarking tool missed. Real-time profiling mostly allows serious performance problems to be identified and fixed within minutes, so it's not irresponsible at all to use it.
Number three: individuals' histories of contributions, both to discussion and to actual code, are normally taken into account by people responding to them.
On Fri, Sep 11, 2009 at 1:36 PM, Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
wrote:
On Fri, Sep 11, 2009 at 3:21 PM, Brian Brian.Mingus@colorado.edu wrote:
apachebench does help with efficiency. It is inefficient (not to mention irresponsible) to wait to benchmark your code until you have a throng of users actually relying on it. Apachebench will allow you to set the
header
needed to trigger the language content shift in mediawiki while simultaneously hammering the server with such requests. Please think
before
being hypercritical of reasonable suggestions.
Number one: suggesting "use apachebench" is not really helpful, because anyone who's even the slightest bit competent knows about it. Although I'm sure you were only trying to be helpful, giving very basic suggestions can be taken to imply that you have a very low opinion of your audience's technical knowledge, and tends to offend people.
Quite the contrary, if I were to engage in a long diatribe about the benefits of apachebench it could be taken to mean I have a very low opinion of my audience's technical knowledge. There are lots of technologies out there, sometimes folks just need a pointer.
Number two: no, it's not inefficient to profile instead of benchmark. Benchmarking is artificial and will not trigger real usage patterns. It's inefficient to waste effort tracking down and fixing performance problems that might not arise in the real world, and at the same time a real-life usage pattern could very easily trigger something your benchmarking tool missed. Real-time profiling mostly allows serious performance problems to be identified and fixed within minutes, so it's not irresponsible at all to use it.
Benchmarking is not artificial by necessity - only by a lack of proper technique. If you can't get accurate profiling data by using benchmarks then you don't know how to benchmark.
Number three: individuals' histories of contributions, both to discussion and to actual code, are normally taken into account by people responding to them.
elitism++. I suppose I should send you my resume before I send my next message to the list.
On Fri, Sep 11, 2009 at 3:42 PM, Brian Brian.Mingus@colorado.edu wrote:
elitism++. I suppose I should send you my resume before I send my next message to the list.
Nobody cares about a piece of paper. We care about what we've personally seen you contribute to our community. That's all that counts here.
On Fri, Sep 11, 2009 at 1:47 PM, Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
wrote:
On Fri, Sep 11, 2009 at 3:42 PM, Brian Brian.Mingus@colorado.edu wrote:
elitism++. I suppose I should send you my resume before I send my next message to the list.
Nobody cares about a piece of paper. We care about what we've personally seen you contribute to our community. That's all that counts here.
You're free to have whatever cognitive biases you like, but its unfortunate that you judge people based on your flawed assumption that you have complete knowledge of folks' contribution histories. (Also unfortunate that you are so quick to make an ad hominem). I've been around longer than you think - why, I remember when Tim was still a wee php hacker learning the ropes. Probably I've been around longer than you, and most of the people who hack on mediawiki. I've been contributing to the projects since the early days in my own ways, which includes core research on quality and creating experimental technologies. I personally find contributing to mediawiki core dull, I like to do things which I perceive to be more interesting, and when I have a result, I present it at Wikimania.
Besides a bunch of code commits, how have you contributed to the projects?
On Fri, Sep 11, 2009 at 3:59 PM, Brian Brian.Mingus@colorado.edu wrote:
On Fri, Sep 11, 2009 at 1:47 PM, Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
wrote:
On Fri, Sep 11, 2009 at 3:42 PM, Brian Brian.Mingus@colorado.edu wrote:
elitism++. I suppose I should send you my resume before I send my next message to the list.
Nobody cares about a piece of paper. We care about what we've personally seen you contribute to our community. That's all that counts here.
You're free to have whatever cognitive biases you like, but its unfortunate that you judge people based on your flawed assumption that you have complete knowledge of folks' contribution histories. (Also unfortunate that you are so quick to make an ad hominem). I've been around longer than you think - why, I remember when Tim was still a wee php hacker learning the ropes. Probably I've been around longer than you, and most of the people who hack on mediawiki. I've been contributing to the projects since the early days in my own ways, which includes core research on quality and creating experimental technologies. I personally find contributing to mediawiki core dull, I like to do things which I perceive to be more interesting, and when I have a result, I present it at Wikimania.
Besides a bunch of code commits, how have you contributed to the projects? _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Please take this off-list. Has 0 relevance to the original topic.
-Chad
2009/9/9 Tisza Gergő gtisza@gmail.com:
The LanguageSelector extension [1] can automatically set the interface language based on browser settings, which is nowadays the norm for every serious multilanguage web page. It is not used on WMF wikis, because it would interfere with caching.
I'm not convinced using the browser language settings for anything other than suggestions is a good practice, as it doesn't necessarily relate at all to language speaking ability of the user behind the browser (think Internet cafes, shared computers, etc.). I notice that it's possible to disable this behavior in the extension and just use it as a UI language picker, which I agree would be useful if we can make it work efficiently.
IMO an approach that replicates the behavior of separate MediaWiki instances on a per-page basis, i.e. where the UI language reflects the content language _of the page_, may be worth considering as well. Then, if you navigate through an entry point in your language, and peruse pages in your language, your UI will be in your language as well, consistently.
Дана Friday 11 September 2009 00:29:54 Erik Moeller написа:
2009/9/9 Tisza Gergő gtisza@gmail.com:
The LanguageSelector extension [1] can automatically set the interface language based on browser settings, which is nowadays the norm for every serious multilanguage web page. It is not used on WMF wikis, because it would interfere with caching.
I'm not convinced using the browser language settings for anything other than suggestions is a good practice, as it doesn't necessarily relate at all to language speaking ability of the user behind the browser (think Internet cafes, shared computers, etc.). I notice that it's possible to disable this behavior in the extension and just use it as a UI language picker, which I agree would be useful if we can make it work efficiently.
I believe I can say as a professional that you are correct, albeit it is my opinion that the browser settings can be usefully used as long as you leave the user quick, simple and obvious ability to change the language on his own.
One thing that would be *extremely* useful regardless is the ability to keep a language throughout the browsing session. This would mean that on, say, Italian Wikipedia, you could have a link to Wikimedia Commons like http://commons.wikimedia.org/wiki/Pagina_principale?uselang=it - and when someone clicks on the featured picture *the interface would stay in Italian* and then when someone clicks on Entra / Registrati *the interface still stays in Italian*, and when someone actually registers the interface becomes Italian in his preferences and so on. This would do a lot for acceptance of Commons among the Wikipedias, and from there I see other useful ways it could be used. If this is done, recognition of the browser language could be more easily be experimented with.
On Fri, Sep 11, 2009 at 3:02 PM, Nikola Smolenski smolensk@eunet.yu wrote:
Дана Friday 11 September 2009 00:29:54 Erik Moeller написа:
2009/9/9 Tisza Gergő gtisza@gmail.com:
The LanguageSelector extension [1] can automatically set the interface language based on browser settings, which is nowadays the norm for every serious multilanguage web page. It is not used on WMF wikis, because it would interfere with caching.
I'm not convinced using the browser language settings for anything other than suggestions is a good practice, as it doesn't necessarily relate at all to language speaking ability of the user behind the browser (think Internet cafes, shared computers, etc.). I notice that it's possible to disable this behavior in the extension and just use it as a UI language picker, which I agree would be useful if we can make it work efficiently.
I believe I can say as a professional that you are correct, albeit it is my opinion that the browser settings can be usefully used as long as you leave the user quick, simple and obvious ability to change the language on his own.
One thing that would be *extremely* useful regardless is the ability to keep a language throughout the browsing session. This would mean that on, say, Italian Wikipedia, you could have a link to Wikimedia Commons like http://commons.wikimedia.org/wiki/Pagina_principale?uselang=it - and when someone clicks on the featured picture *the interface would stay in Italian* and then when someone clicks on Entra / Registrati *the interface still stays in Italian*, and when someone actually registers the interface becomes Italian in his preferences and so on. This would do a lot for acceptance of Commons among the Wikipedias, and from there I see other useful ways it could be used. If this is done, recognition of the browser language could be more easily be experimented with.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I looked at this exact issue before (there's a bug for it too). It should be _very_ trivial to set uselang values into the session or a cookie. Right now uselang= only works on the page you're on, which isn't ideal.
-Chad
wikitech-l@lists.wikimedia.org