If the stressor point is a few hundred hits, lets pick a value low enough not to risk reaching the max, but high enough to not risk excessive collateral damage, Something along the lines of 40-50 would avoid most accidental triggers and low enough to limit server stress.
Its far better to incrementally step the limit down, to reach optimal values than to cut back radically and piss everyone off until you can raise the threshold On Mon, May 18, 2015 at 9:25 PM, Nikolas Everett <never...@wikimedia.org> wrote: > On Mon, May 18, 2015 at 8:50 PM, MZMcBride <z...@mzmcbride.com> wrote: > > > Jonathan Morgan wrote: > > >On Mon, May 18, 2015 at 5:08 PM, Bahodir Mansurov > > ><bmansu...@wikimedia.org> wrote: > > >> I doubt all 200 students will be making concurrent searches. > > > > > >I can easily imagine a scenario where 200 students in a large lecture > > >classroom might be instructed to open their laptops, go to Wikipedia, > and > > >search for a particular topic at the same time. Similar to how teachers > > >[used to] say "now everyone in the class turn to Chapter 8...". > > > > > >If that is indeed what we're talking about here, it will be disruptive. > > > > I imagine the more common cases involve either distributing a URL or > > instructing students to search for a particular topic, which typically > > routes through Google or Yahoo! or some external search engine. Both of > > these cases wouldn't be disrupted, as I understand it. > > > > We'll still keep an eye on it. More worrying is the assertion that some > countries come through a surprisingly small number of IP for some reason. > I've got a pretty itchy rollback finger and deploy rights. > > > > > That said, I'm not sure what this thread is about. What problem are we > > trying to solve? Are we having issues with concurrent searches? Does > > anyone have links to Phabricator Maniphest tasks or Gerrit commits? > > > > > This is the last of some security recommendations brownout a few months ago > caused by someone finding an inefficient query and _hammering_ the reload > button a couple hundred times. I'd link to the bug but it contains > reproduction steps so its under some level of lock and key. The fix is > us-specific so it's possible the issue is repeatable against other > Lucene/Elasticsearch/SOLR users. As I said we've since prevented it from > being exploitable on our side. > > If we have to increase the limits or add whitelists we will. It'll be nice > to have some protection but I'm sensitive to it causing trouble. > > I expect Erik will be monitoring the logs tonight PDT time and I'll have a > look early tomorrow morning EDT. The relevant commit in gerrit is > https://gerrit.wikimedia.org/r/#/c/210622/ . > > Nik > _______________________________________________ > 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
