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 <neverett(a)wikimedia.org>
wrote:
On Mon, May 18, 2015 at 8:50 PM, MZMcBride
<z(a)mzmcbride.com> wrote:
Jonathan Morgan wrote:
>On Mon, May 18, 2015 at 5:08 PM, Bahodir Mansurov
><bmansurov(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l