Colo in Africa

Gregoire Ehoumi gregoire.ehoumi at yahoo.fr
Tue Jul 16 23:20:13 UTC 2019


Ken,You can have useful information in AFNOG mailing list (afnog at afnog.org).--Gregoire Ehoumi------ Original message------From: Ken GilmourDate: Tue, Jul 16, 2019 6:48 PMTo: C. A. Fillekes;Cc: North Group;Subject:Re: Colo in AfricaWhat matters is whether or not we can get a facility in Africa to provide service to our customers from Bare Metal Servers :)On Tue, 16 Jul 2019 at 16:07, C. A. Fillekes <cfillekes at gmail.com> wrote:Are they refreshing data they've already got, though? This is the classic use case for client-side caching. On Tue, Jul 16, 2019 at 5:56 PM Ken Gilmour <ken.gilmour at gmail.com> wrote:We have a different use case to traditional analytics - We're aimed at consumers and small businesses, so instead of a SOC with one big screen refreshing 10000 rows of only alert data every 30 seconds, we have thousands of individuals refreshing all of their data every 30 seconds because there are comparatively less alerts for individuals than enterprises.What you "should" do often doesn't translate to what you "do" do.On Tue, 16 Jul 2019 at 11:23, Valdis Kl??tnieks <valdis.kletnieks at vt.edu> wrote:On Tue, 16 Jul 2019 10:39:59 -0600, Ken Gilmour said:

> These are actual real problems we face. thousands of customers load and
> reload TBs of data every few seconds on their dashboards.

If they're reloading TBs of data every few seconds, you really should have been
doing summaries during data ingestion and only reloading the summaries.
(Overlooking the fact that for dashboards, refreshing every few seconds is
usually pointless because you end up looking at short-term statistical spikes
rather than anything that you can react to at human speeds.?? If you *care* in
real time that the number of probes on a port spiked to 457% of average for 2
seconds you need to be doing automated responses....

Custom queries are more painful - but those don't happen "every few seconds".



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190716/1390e107/attachment.html>


More information about the NANOG mailing list