On various Vector feedback pages as well as on OTRS many people report that since the switch to Vector it takes significantly more time for Wikipedia pages to load.
I didn't think that i experience significant slowness myself, but after seeing a few reports i tried to measure it in a very non-precise way: I loaded [[The Holocaust]], a long article with a lot of images. It took 25 seconds with Vector and 15 seconds with Monobook. I did both measurements after cleaning the cache.
Some other articles: * [[Slavery in the United States]] - 13 sec. on Vector, 7 sec. on Monobook * [[Jehova's Witnesses]] - 10 sec. on Vector, 6 sec. on Monobook * [[Nuclear program of Iran]] - 14 sec. on Vector, 9 sec. on Monobook.
Seems quite consecutive, but i'm not a professional website performance tester.
Are there any more precise measurements?
Are there proper bugs reports about it? (I searched Bugzilla for "Vector slow" and didn't find anything.)
2010/5/20 Amir E. Aharoni amir.aharoni@mail.huji.ac.il:
Are there any more precise measurements?
Are there proper bugs reports about it? (I searched Bugzilla for "Vector slow" and didn't find anything.)
There are no bugs in Bugzilla for this, currently. I will dive into this and find out where the slowness is coming from (could be a lot of different things), but I'm quite busy at the moment and spending any work time I do get on fixing bugs, so it'll take some time before I get around to this.
If anyone else feels like analyzing what the slow parts are (I recommend Firebug's net panel as one tool for investigating this), by all means go ahead and post your findings here.
Roan Kattouw
For others interested, it's now been filed in bugzilla: https://bugzilla.wikimedia.org/show_bug.cgi?id=23612
On Fri, May 21, 2010 at 2:04 AM, K. Peachey p858snake@yahoo.com.au wrote:
For others interested, it's now been filed in bugzilla: https://bugzilla.wikimedia.org/show_bug.cgi?id=23612
Forgot my bugzilla login, so here: [[The Holocaust]] Google Chrome 5.0.375.38 beta on Windows XP Vector : 6.4 +- 0.2 sec Monobook : 5.5 +- 0.1 sec
On 05/20/2010 09:15 AM, Amir E. Aharoni wrote:
On various Vector feedback pages as well as on OTRS many people report that since the switch to Vector it takes significantly more time for Wikipedia pages to load.[...]
Are there any more precise measurements?
I don't know how useful it is, but recently I helped a client build some JS-based, in-browser page load performance monitoring. It tracks various rendering events of a chosen percentage of pageviews. The only server-side code processes web server logs in batch, so it is pretty low impact, and works with cached pages. It's been served in a few hundred million pageviews with no obvious problems yet.
I think most of the server-side code is pretty particular to their needs, but if somebody wants it for Wikipedia, I'm sure they'd be willing to give up the client-side stuff and my rough-and-ready initial pass at the log parsing, which is in Ruby. If that's useful, let me know off-list and I'll ask 'em for permission.
William
2010/5/22 William Pietri william@scissor.com:
I don't know how useful it is, but recently I helped a client build some JS-based, in-browser page load performance monitoring. It tracks various rendering events of a chosen percentage of pageviews. The only server-side code processes web server logs in batch, so it is pretty low impact, and works with cached pages. It's been served in a few hundred million pageviews with no obvious problems yet.
I think most of the server-side code is pretty particular to their needs, but if somebody wants it for Wikipedia, I'm sure they'd be willing to give up the client-side stuff and my rough-and-ready initial pass at the log parsing, which is in Ruby. If that's useful, let me know off-list and I'll ask 'em for permission.
I'm not sure we need this. I don't see a reason why one of us usability developers can't just load pages, find out whether they're slower, and where the slowness is. If the slowness is present for everyone (many different people reporting slowness seems to indicate that, and I have no reason to believe otherwise) you don't need to jump through hoops to gather data from random users when you can easily reproduce it yourself.
Roan Kattouw (Catrope)
On 05/21/2010 03:39 PM, Roan Kattouw wrote:
I'm not sure we need this. I don't see a reason why one of us usability developers can't just load pages, find out whether they're slower, and where the slowness is. If the slowness is present for everyone (many different people reporting slowness seems to indicate that, and I have no reason to believe otherwise) you don't need to jump through hoops to gather data from random users when you can easily reproduce it yourself.
I'm not sure you need it either; I just thought I'd offer what I had on hand. But the reason we built it was to quantify the problem so we could narrow down and prioritize issues.
There are a lot of variables in browser performance, and we found it frustrating to try to simulate various user conditions (OS versions, browser versions, physical location, bandwidth) and get solid, statistically valid measurements that we thought correlated well with what people were actually experiencing. After enough futzing with that, it was a relief to get some actual numbers rolling in automatically.
Last I heard they were going to set it up to graph aggregate client-side performance over time, so that they could easily see if their normal feature changes had unexpected browser performance impact. They want to solve the problems before users complain. So few of them do, especially about something subtle like performance.
William
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 37-01--10 03:59 PM, William Pietri wrote:
They want to solve the problems before users complain. So few of them do, especially about something subtle like performance.
Luckily, our userbase loves complaining, and is good at it, so they do it fairly often :)
- -Mike
wikitech-l@lists.wikimedia.org