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
next prev 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