https://bugzilla.wikimedia.org/show_bug.cgi?id=37616
Fabrice Florin <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|[email protected] |[email protected] --- Comment #2 from Fabrice Florin <[email protected]> 2012-06-15 17:51:54 UTC --- On Jun 14, 2012, at 9:37 PM, Roan Kattouw wrote: I'm not sure if the code exists in AFT5, but it should still be in AFT4. It's called the lottery. The principle is very simple: if ( articleID % 1000 < lotteryOdds ) { article wins lottery, gets AFT } else { article does not win lottery; do not pass go, do not collect $200 } lotteryOdds is the number of articles out of a thousand that get AFT (so if lotteryOdds=15, then 1.5% of all pages get AFT, specifically the pages where the last three digits of the page ID are between 000 and 014 inclusive). Basing it on the page ID ensures that the set of pages that get AFT for a certain value of lotteryOdds is stable, and that articles are never dropped from, but only added to, this set as the value of lotteryOdds increases. For deployment, you'd do something like this: 1. Deploy lottery code with lotteryOdds=0, check a few articles (including one whose page ID ends in 000) to verify no one wins the lottery 2. Increase the value of lotteryOdds a little 3. Wait for the change to propagate through the caches 4. Check that the lottery is working correctly. When raising lotteryOdds from, say, 10 to 15, you would check: 4a. a page with a page ID ending in 009 or lower (should already have won before, should still win now) 4b. a page with a page ID ending in 010 (should not have won before, should win now) 4c. a page with a page ID ending in 014 (same) 4d. a page with a page ID ending in 015 (should not win just yet) 5. Wait for a while *after the caches have cleared* and keep an eye on the health of things in Ganglia 5a. If bad things happen, drop lotteryOdds back to its previous value and give up for now 5b. If things hold up OK, go back to step 2 and repeat until lotteryOdds has reached 100 (=10.0%) Notes: * A reasonable sequence of values for lotteryOdds would be 1, 5, 10, 20, 50, 100 * To find articles whose page ID ends in a certain set of digits and that are in the main namespace (otherwise AFT shouldn't show up regardless), you can run the following query on the toolserver: SELECT page_id, page_title FROM page WHERE page_namespace=0 AND page_id MOD 1000 = 15; ** Please run this on the toolserver (or another non-production database replica like the one analytics has), don't run it on the production database. IF you don't have toolserver access, apply for an account or enlist someone who does (Dario?) * The value of lotteryOdds should be exported to JS using the ResourceLoaderGetConfigVars hook (don't use the MakeGlobalVariablesScript hook for this! Its results are much more aggressively cached for anons). Variables exported through this hook have a low cache timeout (5 minutes) but unfortunately invalidation isn't automatic, you have to trigger it yourself. To do this, run "touch php-1.20wmfN/resources/startup.js" followed by "sync-file php-1.20wmfN/resources/startup.js", then wait for the cache to clear. The server-side cache should clear within 5 minutes, after that your browser's cache may take up to 5 minutes as well * To test whether the cache has cleared, check if AFT appears on articles that didn't win the lottery before but should win it now (see 4a-4d), and test this in incognito mode * After the caches have cleared, you should wait about 15 minutes before increasing lotteryOdds again. The reasons for this are: ** After you start getting JS with the new value, it may take up to 5 minutes before everyone gets it. Because different people's browsers' caches will expire at different moments, the change will gradually reach readers over the course of about 5 minutes. ** Then once the change has reached everyone, you should wait 10 minutes to see if anything strange happens * Bad things that might happen include: ** A noticeable increase in load / network traffic / packet loss that persists and that, when extrapolated to lotteryOdds=100, would be a significant increase ** Services going down in Nagios (reported by nagios-wm in either #wikimedia-tech or #wikimedia-operations , I forget which) *** If something goes down, comes back up, and stays up, it's probably fine. If it stays down or keeps flapping, it's probably bad. When in doubt as to whether your changes could've caused a certain Nagios alert, ask ops The lottery would be in addition to the whitelists and blacklist: 1) articles on the blacklist should not get AFT even if they win the lottery, and 2) articles on the whitelists should get it even if they lose the lottery. Roan [Fabrice note: To be even more specific, this method would honor existing black list and white list restrictions by removing from this 10% sample any article that is in the blacklist, or that is a re-direct. We would also continue to include in the 10% sample any article from there whitelists, which include both the hidden category 'Article_Feedback_5' and this 'Additional_Articles' category (so we can continue to manually add articles to it, as needed for special cases): http://en.wikipedia.org/wiki/Category:Article_Feedback_5_Additional_Articles ] -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
