Re: [Wikitech-l] [RFC] performance standards for new mediawiki features
From where would you propose measuring these data points? Obviously network latency will have a great impact on some of the metrics and a consistent location would help to define the pass/fail of each test. I do think another benchmark Ops features would be a set of latency-to-datacenter values, but I know that is a much harder taks. Thanks for putting this together. On Thu, Mar 21, 2013 at 6:40 PM, Asher Feldman afeld...@wikimedia.orgwrote: I'd like to push for a codified set of minimum performance standards that new mediawiki features must meet before they can be deployed to larger wikimedia sites such as English Wikipedia, or be considered complete. These would look like (numbers pulled out of a hat, not actual suggestions): - p999 (long tail) full page request latency of 2000ms - p99 page request latency of 800ms - p90 page request latency of 150ms - p99 banner request latency of 80ms - p90 banner request latency of 40ms - p99 db query latency of 250ms - p90 db query latency of 50ms - 1000 write requests/sec (if applicable; writes operations must be free from concurrency issues) - guidelines about degrading gracefully - specific limits on total resource consumption across the stack per request - etc.. Right now, varying amounts of effort are made to highlight potential performance bottlenecks in code review, and engineers are encouraged to profile and optimize their own code. But beyond is the site still up for everyone / are users complaining on the village pump / am I ranting in irc, we've offered no guidelines as to what sort of request latency is reasonable or acceptable. If a new feature (like aftv5, or flow) turns out not to meet perf standards after deployment, that would be a high priority bug and the feature may be disabled depending on the impact, or if not addressed in a reasonable time frame. Obviously standards like this can't be applied to certain existing parts of mediawiki, but systems other than the parser or preprocessor that don't meet new standards should at least be prioritized for improvement. Thoughts? Asher ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Abuse of +2 Powers in Core and Extensions
This only applies to DonationInterface and fundraising code, but self-review also put us in PCI non-compliance [1]. We currently operate at the self-assessed and certified PCI level A, but we have not precluded formal certification at a higher level. [1] - PCI-DSS v2 - 6.3.2 https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf On Wed, Feb 27, 2013 at 11:30 AM, Matthew Walker mwal...@wikimedia.orgwrote: All, I noticed when going through recent patches to DonationInterface that we had an instance of someone not in fundraising self commit some code -- similar changes resulting from the same 'bug' were affected across our code base. Admittedly this was was a minor textual fix - but as per [1] Except for documentation fix-ups, don't +2 your own code. 'Self-review is bad for code quality and bad for morale.' I will admit I was in a terrible mood already today -- but discovering this pissed me off. I am a strong advocate of never +2'ing your own code; and this is especially true when you don't own the code in question. I don't want to see this again. [1] https://www.mediawiki.org/wiki/%2B2#Revocation ~Matt Walker Wikimedia Foundation Fundraising Technology Team ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] suggestion: replace CAPTCHA with better approaches
On Tue, Jul 24, 2012 at 4:18 PM, Steven Walling steven.wall...@gmail.comwrote: On Tue, Jul 24, 2012 at 2:52 PM, Leslie Carr lc...@wikimedia.org wrote: I agree that better tools and non captcha based tech are the way to go. At a previously very-spammed company, we learned how no matter how badly you distort the captchas, it doesn't matter, as if it's human readable, humans can pick out the text. Look how cheap it is to get a human to do your captchas for the spammers! http://decaptchablog.com/decaptcher-services Technical/social solutions such as helping the community patrol and catch spam and automated detection of spammy language are the way to go Leslie P.S. This is my own personal opinion and not the opinion of the foundation P.P.S. I also vote for any proposal which increases the number of kittens I get to view on a daily basis. What about a honey pot? https://en.wikipedia.org/wiki/Honeypot_(computing) Steven Tarpits are so much more fun. http://en.wikipedia.org/wiki/Tarpit_(networking) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Please preload a space in the page for the banner
FWIW, we have pretty much standardized on a banner height of 172px and, to my knowledge, have no plans to modify that. If we did, it would get smaller and not larger. On Mon, Nov 21, 2011 at 2:42 PM, Ryan Kaldari rkald...@wikimedia.orgwrote: This has already been hashed out technically, and is doable. The only issue is getting people to standardize on a banner size, which I've tried for the past few months to get people to agree on, but with no luck. In order for this to work we need a benevolent dictator (Zach?, Erik?) to state that all banners (including chapter banners) need to be a certain height during the fundraiser. As it's not a high priority issue currently, I'm not sure if there's any likelihood of that actually happening. If people want to discuss further, the bug is at: https://bugzilla.wikimedia.org/show_bug.cgi?id=26234 Ryan Kaldari On 11/20/11 3:42 AM, Roan Kattouw wrote: On Sun, Nov 20, 2011 at 12:37 PM, David Gerarddger...@gmail.com wrote: A Wikipedia page loads. The last thing to load is the banner. This pushes the page content down. If you've clicked on a link near the top of the page, the banner grabs it instead. This happened last year and it was reported then (and it was incredibly annoying then too). It also fouls up stats on banner effectiveness, as banners are clicked on without intention to do so. Please load the page with a space for the banner to avoid this effect. CC fr-tech. This should be doable provided that all banners have the same dimensions. Which banner will be selected (if one is selected at all) is determined by JS and is not known by PHP (and can't be known by PHP due to Squid caching). Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Please preload a space in the page for the banner
On Mon, Nov 21, 2011 at 4:18 PM, David Gerard dger...@gmail.com wrote: On 22 November 2011 00:14, Peter Gehres li...@pgehres.com wrote: On Mon, Nov 21, 2011 at 2:42 PM, Ryan Kaldari rkald...@wikimedia.org wrote: This has already been hashed out technically, and is doable. The only issue is getting people to standardize on a banner size, which I've tried for the past few months to get people to agree on, but with no luck. In order for this to work we need a benevolent dictator (Zach?, Erik?) to state that all banners (including chapter banners) need to be a certain height during the fundraiser. As it's not a high priority issue currently, I'm not sure if there's any likelihood of that actually happening. If people want to discuss further, the bug is at: https://bugzilla.wikimedia.org/show_bug.cgi?id=26234 FWIW, we have pretty much standardized on a banner height of 172px and, to my knowledge, have no plans to modify that. If we did, it would get smaller and not larger. That doesn't appear to square with Ryan's statement. Is the banner height really 172px, i.e. will a 172px preloaded space really solve the problem? - d. I am in a better position to comment about banner size than Kaldari. It's not necessarily a good solution as we plan to bring the banners down for logged in users fairly soon. I assume that they would rather not have the jump in the reverse direction :-) I'm sure that we could have two separate pre-loaded empty divs (one for anon, and one for logged in) but that still does not account for project, language, and country variations. Additionally, it has yet to be determined whether or not reserving the space has an effect on click rate. I could see reasons why it could effect it both positively and negatively. - Peter ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
