Last modified: 2014-11-05 19:00:25 UTC
curl -I 'http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.wikimediaShopLink.core%7Cjquery.client%2Ccookie%2CmwExtension%7Cmediawiki.cldr%2CjqueryMsg%2Clanguage%2Cnotify%2Cutil%7Cmediawiki.language.data%2Cinit%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup&skin=vector&version=20121203T183954Z&*' curl: (52) Empty reply from server
Works for me - is this still an issue, and on which continent are you based? There were some load issues but they are mostly fixed now.
Works from 81.169.0.0/16, but *NOT* from 78.52.0.0/16 (Europe/Berlin/dynamic IP for DSL endpoint)
(In reply to comment #2) > Works from 81.169.0.0/16, but *NOT* from 78.52.0.0/16 (Europe/Berlin/dynamic > IP > for DSL endpoint) Is the routing to the bits servers ok from both ip address ranges?
I'm wondering if this is a dup of bug 41130?
This appears to be a *script bug* in http://bits.wikimedia.org/en.wikipedia.org/load.php because the server itself shows no problems at all.
As we've changed data centers in late January and the related setup, could you please test if this is still a problem?
Yes, it is still a problem. See the screenshot.
Created attachment 11898 [details] screenshot of timeout in firebug
For me in Firebug that specific call is 51ms and 14.9kb (being logged in), for you 11440ms and 0.0kb. And in my case the URL is http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.wikimediaShopLink.core%7Cjquery.client%2Ccookie%2CmwExtension%7Cmediawiki.cldr%2CjqueryMsg%2Clanguage%2Cnotify%2Cutil%7Cmediawiki.language.data%2Cinit%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup%7Cwikibase.client.init&skin=vector&version=20130311T110922Z&*
Just realizing that this question still stands: > Is the routing to the bits servers ok from both ip address ranges?
Look at the screenshot. Just one out of multiple calls to the same script fails. So the routing is definitely ok.
Andre: we have already determined that it is a problem related to the source ip range.
Bug 39322 came to my mind, so I'd still appreciate the output of the following commands traceroute bits.wikimedia.org curl -i http://bits.wikimedia.org/
This seems to something like my ongoing Wikipedia/Wikimedia problem. In last 12 hours most of queries to http://bits.wikimedia.org from my home IP are failed, but not all. However https://bits.wikimedia.org seems to work normally. I also asked in community portal of fiwiki if wikipedia has been slow and answer was it has been worked normally. Commands asked: --- CLIP ---- curl -i http://bits.wikimedia.org/ curl: (7) Failed to connect to 2620:0:862:ed1a::a: Network is unreachable --- CLIP ---- curl -i https://bits.wikimedia.org/ HTTP/1.1 200 OK Server: nginx/1.1.19 Date: Wed, 08 May 2013 05:45:54 GMT Content-Type: text/html Content-Length: 178 Connection: keep-alive Last-Modified: Thu, 12 Aug 2010 16:12:20 GMT ETag: "b2-48da2a1772100" X-Varnish: 693529009 Via: 1.1 varnish Accept-Ranges: bytes X-Varnish: 1488468153 Age: 0 Via: 1.1 varnish X-Cache: strontium miss (0), cp3021 miss (0) <html> <head><title>bits and pieces</title> <meta http-equiv="refresh" content="1;url=http://www.wikimedia.org/" /> </head> <body> bits and pieces live here! </body> </html> --- CLIP ---- curl -i http://bits.wikimedia.org/geoiplookup HTTP/1.1 200 geoiplookup Server: Varnish Content-Type: text/javascript Content-Length: 111 Last-Modified: Wed, 08 May 2013 05:58:57 GMT Cache-Control: private, max-age=86400, s-maxage=0 Accept-Ranges: bytes Date: Wed, 08 May 2013 05:58:57 GMT X-Varnish: 2987799549 Age: 0 Via: 1.1 varnish Connection: close X-Cache: cp3022 miss (0) Geo = {"city":"REMOVED","country":"FI","lat":"REMOVED","lon":"REMOVED","IP":"91.153.84.229","netmask":"24"} --- CLIP ---- traceroute bits.wikimedia.org traceroute to bits.wikimedia.org (91.198.174.233), 30 hops max, 60 byte packets 1 kotiboksi.Elisa (192.168.100.1) 0.662 ms 0.861 ms 1.079 ms 2 tkueur1.fi.elisa.net (91.153.48.1) 14.876 ms 15.553 ms 15.781 ms 3 ge1-0-0.tkubra-p1.fi.elisa.net (139.97.9.13) 13.879 ms 15.328 ms 16.106 ms 4 so7-2-0.esptnl-p1.fi.elisa.net (139.97.6.1) 19.842 ms 21.924 ms 22.199 ms 5 ip-rr.hkika234.fi.elisa.net (139.97.0.162) 22.454 ms 23.130 ms 23.885 ms 6 213.192.184.109 (213.192.184.109) 25.150 ms 17.379 ms 18.065 ms 7 as0-0.bbr1.ams1.nl.eunetip.net (213.192.191.226) 54.601 ms 50.913 ms 47.484 ms 8 * * * 9 * * * 10 * * * .... Discussion in community portal: http://fi.wikipedia.org/wiki/Wikipedia:Kahvihuone_%28tekniikka%29#Wikipedian_hidastelu
And little bit more. In my case it is maybe just only DNS updating problem. In my home ip bits.wikimedia.org resolves to 91.198.174.233, 2620:0:862:ed1a::a, bits.esams.wikimedia.org. In .kapsi.fi where everything is working fine bits.wikimedia.org resolves to 2620:0:861:ed1a::a, 208.80.154.234, bits-lb.eqiad.wikimedia.org
Yeah, bits was having issues earlier today. https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&oldid=69483 and http://status.wikimedia.org/8777/156486/Static-assets-(CSS/JS) seem to confirm this. I think separate issues are getting mixed in to a single bug, though.
Correct, comment 14 - comment 17 are a different issue.
Every time I look (e.g. on webpagetest.org), I always find one or two "failing" load.php calls however I test it. Usually it's the CentralNotice taking too much, I don't see what can be done in this component.
This happens reliably on the IP range my ISP uses (looks like 86.141.0.0/16), when jqueryMsg is in the query string: This times out: http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.centralauth.centralautologin%7Cext.uls.init%2Cinterface%2Cpreferences%2Cwebfonts%7Cext.visualEditor.viewPageTarget.init%7Cjquery.accessKeyLabel%2CbyteLength%2Cclient%2Ccookie%2CmwExtension%2CtabIndex%2Cthrottle-debounce%2Ctipsy%7Cmediawiki.Title%2CUri%2Capi%2Ccldr%2CjqueryMsg%2Clanguage%2Cnotify%2Cuser%2Cutil%7Cmediawiki.language.init%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup%7Cmmv.base%2Chead%7Cskins.vector.js&skin=vector&version=20141031T180422Z&* This returns: http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.centralauth.centralautologin%7Cext.uls.init%2Cinterface%2Cpreferences%2Cwebfonts%7Cext.visualEditor.viewPageTarget.init%7Cjquery.accessKeyLabel%2CbyteLength%2Cclient%2Ccookie%2CmwExtension%2CtabIndex%2Cthrottle-debounce%2Ctipsy%7Cmediawiki.Title%2CUri%2Capi%2Ccldr%2Clanguage%2Cnotify%2Cuser%2Cutil%7Cmediawiki.language.init%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup%7Cmmv.base%2Chead%7Cskins.vector.js&skin=vector&version=20141031T180422Z&*
(In reply to Macavity from comment #19) > This happens reliably on the IP range my ISP uses (looks like > 86.141.0.0/16), when jqueryMsg is in the query string: > > This times out: Works for me as I get a cached response /* cache key: enwiki:resourceloader:filter:minify-js:7:519abda9a1640250a7c561ccfd0f22f8 */ I don't see ongoing CentralNotice campaigns for UK.
Here is a Chrome plugin that provides a workaround: https://chrome.google.com/webstore/detail/wikipedia-speedup/ppmagkdpdaaabpmdppckemgkngkpchdl?hl=en
