Last modified: 2013-06-11 06:40:27 UTC
Hi! Looks like bits.wikimedia.org is fetched more often after Universal Language Selector was installed on Commons. For example, open file page, open user talk page, delete file, wait for action complete. This make page slower to load and likely increase traffic and servers load. Similar issues could be observed on Wikidata. I don't change language in process. Eugene. PS I use Mozilla FIrefox 21 on Windows XP.
Could you provide some data what "slower" means (e.g. via Firebug and/or Firefox Developer Tools)? Do you know if other users (Village Pump discussions etc.) have also faced this problem?
Browser waiting while reading bits.wikimedia.org much more often. Before USL deployment it was ~ once in 20 minutes. I think Live HTTP headers will be best tool to investigate problem. Previous discussion about frequent bits.wikimedia.org fetches was in wikitech mailing list.
Note to myself: wmf4 was deployed on May 15 to Commons, ULS on May 20: https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log&diff=71004&oldid=71003 Still needs some specific data in this bug report, e.g. for "reading bits.wikimedia.org much more often" - filenames, time it takes until loading successfully etc. In my case (using Firebug), some fonts seem to not load successfully, e.g. https://bits.wikimedia.org/static-1.22wmf4/extensions/UniversalLanguageSelector/data/fontrepo/fonts/IranianSans/IranianSans.woff?version=1.0&20120101
Created attachment 12393 [details] Live HTTP Headers log I opened file page, user contributions page, user talk page, then left message on user talk page and deleted file.
Created attachment 12394 [details] Live HTTP Headers log I opened file page, user contributions page, user talk page, then left message on user talk page and deleted file.
I attached couple of Live HTTP Headers logs. My actions: I opened file page, user contributions page, user talk page, then left message on user talk page and deleted file. Logs were made in "warm" state, after several of similar deletions.
The content of attachment 12393 [details] has been deleted by Sam Reed (reedy) <sam@reedyboy.net> who provided the following reason: Personal data The token used to delete this attachment was generated at 2013-05-25 14:55:50 UTC.
The content of attachment 12394 [details] has been deleted by Sam Reed (reedy) <sam@reedyboy.net> who provided the following reason: Personal data The token used to delete this attachment was generated at 2013-05-25 14:56:08 UTC.
I don't see any reliable data here yet what "slow" exactly means, hence it's also impossible to define/discuss what is "too" slow. It's normal that loading takes longer if more stuff gets loaded, so I don't see a valid bug yet. If it is extremely slow, please provide data (without personal data included).
Sorry, my log file were deleted because of personal data. I could sent them via e-mail. You could try to reproduce them with Firefox Live HTTP Headers extension yourself of both Commons and Wikidata. Just in case: I use User Messages and Quick Delete gadgets on Commons, slurpInterwiki, Preview, labelLister, AuthorityControl, CommonsMedia gadgets on Wikidata. Please don't forget that not everybody has fast Internet connection or free unlimited traffic. So forcing more traffic because of extension (mostly decorative in my case) is bad idea. Alternatively extension could provide way to turn off functionality completely.
(In reply to comment #10) > Sorry, my log file were deleted because of personal data. That should not block you from defining what "slower" means. :) > So forcing more traffic because of extension (mostly > decorative in my case) is bad idea. The improvements provided by the extension are considered more important than the amount of additional traffic (about how many bytes do we talk?). If you want to avoid costs I'd rather switch off images by default, etc.
I think you could try 56 kbit mode to replicate slowness :-) Please note that if extension functionality is not used, its value is equal to zero. Images may provide value for user, but almost constant fetching of bits.wikimedia.org without apparent reason is not.
To clarify, is this merely about time spent transferring data from the server or other problems like timeouts, repeated HTTP requests, CPU usage, memory consumption and so on? Does it happen on all page loads or is it something that happens occasionally (albeit too frequently) as this seems to suggest: (on comment #2) > Browser waiting while reading bits.wikimedia.org much more often. Before USL > deployment it was ~ once in 20 minutes. ? This is the kind of clarification about "slowness" that devs are seeking, I think.
I think it mostly transferred data size related. From point of view that bits.wikimedia.org content should not be changed every minute, it's repeated HTTP requests. It happens not for every opened page, but at least for majority of opened pages.
Providing an option to disable ULS is not planned, see bug 46306. Note though that ULS can be disabled for anonymous users (bug 42157). I still cannot see a valid bug in this report.
Sorry, I tried my best to explain a problem. Please try Live HTTP headers. If you'll notice repeated accesses to bits.wikimedia.org, it's good idea to investigate why it happens. If bits.wikimedia.org was not changed at that time, such fetching is waste of time and bandwidth on bot WMF servers and users sides.
Closing this as works for me. No actionable data has come to light in the past 16 comments.
