public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Stefan Schantl <stefan.schantl@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Next steps of IPFire Location
Date: Thu, 19 Nov 2020 19:49:27 +0100	[thread overview]
Message-ID: <331c8cfa1af4ec5b0fab1461e6df7c571bb76c6f.camel@ipfire.org> (raw)
In-Reply-To: <C083DD5F-3310-4BB5-90EC-B08450453075@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 2651 bytes --]

Hello Michael,

I've installed the latest Core 153 from unstable Branch and benchmarked
the location database export on my IPfire Mini Appliance.

[root(a)gate ~]# time location export --directory=/tmp --format=xt_geoip

real    0m53.629s
user    0m52.144s
sys     0m0.702s

Best regards,

-Stefan
> I managed to export the database on my IPFire Mini Appliance in about
> one minute:
> 
> [root(a)fw01 libloc]# time location export --directory=tmp --
> format=xt_geoip
> 
> real    1m3.423s
> user    1m1.470s
> sys     0m1.009s
> 
> The system was under a little bit of load due to some network
> activity, but I am generally quite happy with this.
> 
> I added some more fine-tuning and could decrease the export time on
> my Debian test machine by another 40% to around six seconds.
> 
> -Michael
> 
> > On 18 Nov 2020, at 19:26, Michael Tremer <michael.tremer(a)ipfire.org
> > > wrote:
> > 
> > Hello,
> > 
> > Since there are now so many people involved in this project, I
> > would like to send a little email to report what has happened and
> > what the next steps are going to be…
> > 
> > I have spent (unfortunately) a lot of time to add the ability that
> > we can “flatten the tree” when we export it. That means that no
> > network will overlap with another one and we do not need to care
> > about any orders of iptables rules being added.
> > 
> > That was quite a slow process in Python and since IPFire has to run
> > on small hardware it needed to be ported into C. The tree can now
> > be exported in about 10 seconds on my development box which is
> > running an Intel Xeon E5-2630 processor.
> > 
> > I hope that we can reach acceptable times of only a few minutes on
> > the slowest systems and way under a minute on an average system. To
> > find out about that, I need you help:
> > 
> > I just pushed all changes into the next tree and would everyone who
> > can to install that and report how long this command runs:
> > 
> >  mkdir tmp
> >  time location export --directory=tmp --format=xt_geoip
> > 
> > It would also be great if you could all check the output if this is
> > still correct. I have done what I could, but I want to have an
> > extra pair of eyes if possible.
> > 
> > If this works well, and no more regressions are being found, I will
> > tag this release and we will close Core Update 153.
> > 
> > We will then roll out all recent changes that make the database
> > better, but had to be held back because the tree needs to be
> > flattened for most use-cases now. All older clients will then no
> > longer receive an updated database any more.
> > 
> > Happy testing.
> > 
> > Best,
> > -Michael


  parent reply	other threads:[~2020-11-19 18:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-18 19:26 Michael Tremer
2020-11-19 13:10 ` Michael Tremer
2020-11-19 17:48   ` Adolf Belka
2020-11-22 20:06     ` Adolf Belka
2020-11-23 11:15       ` Michael Tremer
2020-11-19 18:49   ` Stefan Schantl [this message]
2020-11-20 16:27 ` Peter Müller
2020-11-22 11:59   ` Peter Müller
2020-11-23 11:16     ` Michael Tremer
2020-11-25 20:24       ` Michael Tremer
2020-11-26  7:51         ` Arne Fitzenreiter
2020-11-26 16:21           ` Michael Tremer
2020-11-27  8:03         ` Stefan Schantl
2020-11-27 16:48           ` Michael Tremer
2020-11-28 14:47         ` libloc output for xt_geoip is fine on Core Update 153 Development Build: next/e8ecc81a (was: Re: Next steps of IPFire Location) Peter Müller
2020-12-06 12:35           ` libloc output for xt_geoip is fine on Core Update 153 Development Build: next/e8ecc81a Arne Fitzenreiter
2020-12-06 20:01             ` Michael Tremer
2020-12-07 10:41               ` Adolf Belka
2020-12-07 12:16               ` Arne Fitzenreiter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=331c8cfa1af4ec5b0fab1461e6df7c571bb76c6f.camel@ipfire.org \
    --to=stefan.schantl@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox