[17:22:26] Krinkle: I made a response [17:22:35] Multiversion is one day [17:22:36] One day [17:23:06] My hope is by the time 1.39 comes we'll be on multiversion at Miraheze [17:28:26] RhinosF1: adding a second memcached process with e.g. 10MB of memory wouldn't take up any additional hardware. [17:28:50] Krinkle: would 10MB be useful [17:29:10] sure, it depends on what you want though. [17:29:29] none of memcahced is useful if by the time you need the same thing a second time, the key has been pushed out by the main wiki farm traffic [17:29:29] Like what's the point where it's big enough not be pointless but small enough to meaningfully affect any other wiki [17:29:48] Krinkle: lasts long enough to survive a login session [17:30:04] are you storing login session in memcached? [17:30:06] Like enough to complete central login and be logged in [17:30:10] Krinkle: ye [17:30:27] It stores token in DB in part [17:30:43] I know it can recover from there if lost but not if session is in flight [17:30:51] so if someone slowly crawls through every page via a bot, visting each page once, people get logged out because memcached is pushing out login sessions [17:31:10] login sessions are a stash, not a cache, they do not belong on the same memcached instance [17:31:49] Krinkle: does https://github.com/miraheze/mw-config/blob/master/GlobalCache.php make more sense [17:31:56] Than my messy guesses [17:32:00] 10MB would suffice for speeding up the wiki to persist heavily computed and frequently needed values. [17:32:25] depending on how much traffic you have, you can also consider CACHE_DB [17:32:44] for example, wordpress by default uses a sql table for all caching and is quite succesfull at that for most sites. [17:33:13] that means no global keys by default though, it naturally namespaces it to the wiki db [17:33:26] CosmicAlpha told me CACHE_DB would make DB too big [17:33:54] And I'll get moaned at for being too different to prod [17:34:18] CosmicAlpha: how insane does using a really tiny memcache instance sound [17:34:20] by whom? [17:34:30] By John mostly [17:34:41] define 'too big'. [17:34:44] do you have a parser cache? [17:34:48] Yes [17:34:55] It might be possible for the beta cluster the more I think about it. RhinosF1 [17:35:06] $wgParserCacheType = 'db-replicated'; [17:35:11] that's basically the same as CACHE_DB [17:35:27] anyway, memcached has the benefit of allowing you to control the size budget [17:35:30] CosmicAlpha: what's saner? Using CACHE_DB and telling John it's fine to trust it or setting up a tiny memcache instance [17:35:41] with CACHE_DB it's get bigger indeed, but it'd be disk instead mem which is cheaper. [17:35:56] Krinkle: we had it as simply CACHE_DB for 7 days until like a week ago [17:36:08] I'd recommend a tiny memcached [17:36:27] RhinosF1: maybe memcached can run locally on the test server? But I don't want to request more resources for it. [17:36:36] and yeah, set sessions separately and monitor the metrics you get from your sessionstorerage-memcahced to not cause evictions. [17:36:51] CosmicAlpha: test is like tiny [17:36:58] It needs redis anyway soon for jobs [17:37:06] if you get more active users than you can fit sessions, you'll see it in the graphs and then you can tweak the size to give session-memc more and general-memc less etc. [17:37:27] Beta will never get more active users as account creation is per request [17:37:30] It's not open [17:37:35] Easiest way to stop spambots [17:37:42] I meant the general wiki farm [17:37:51] ah right [17:37:53] I see [17:38:45] it looks like you currently have 2 memc's, presumably of equal size, with main cache distributed among them, and one half re-used for prod sessions and one half for beta sessions. [17:39:15] RhinosF1: you enabled public account creation a couple days ago on beta I saw? So it isn't locked. [17:39:21] I'd maybe go with 3 memcs, 1 for sessions, 1 for main cache, and 1 tiny one for test wiki [17:39:42] then monitor the metrics closely to ensure you give sessionstore enough to avoid early evictions [17:40:52] That's actually a good idea. I've recently changed our setup which improved it, which did just what your saying basically. (I think, unless I did a bit wrong, but it does work much better) [17:50:59] CosmicAlpha: I enabled to test captcha [17:51:05] Which is blocking all as it's broken [18:46:10] hello [18:47:50] it would not be possible to publish the translations of content translation in my workshop even if they are an automatic translation?