[Xorp-hackers] Some performance numbers
Hasso Tepper
hasso@linux.ee
Sat, 25 Feb 2006 09:29:13 +0200
Marko Zec wrote:
> On Thursday 23 February 2006 14:11, Hasso Tepper wrote:
> > Questions ... Is anyone aware of problem? Is it BGP or RIB or IPC or
> > ... problem? Is it worth of effort to open bugreport regarding this?
>
> While it looks like our IPC is quite inefficient at the moment and
> contributes most to the overall system slowness, there's also
> significant room for improvement inside the BGP implementation itself,
> such as path attributes handling code. We have some minor tweaks in
> the pipeline waiting for a stable release to be rolled out first, but
> are just starting to track down the IPC issues.
After writing this I realised that there were some IPC performance numbers
in the NSDI paper. So yes, inefficient IPC explains 60 seconds "put into
RIB/FIB" time. And while looking at it, all - bgp, rib and fea - are
equally busy during this 60 seconds. In "peer down" case bgp itself is
the only process which is really busy though.
> > Can I help with something? I'm not familiar enough with design of
> > XORP and C++ coding yet to solve design related problems though yet.
> > But I have environment and can profile (direction, please?), test
> > patches etc.
>
> Just for the begining could you tell us more about your testing
> environment and methodology, since I'm regularly obtaining
> significantly worse results than what you reported.
Just guess - because I'm using optimised binaries without debug info? I
have modified configure script to use -O3 instead of -O2 and configured
with --disable-debug --enable-optimize. -O3 isn't probably significantly
better than -O2, I just wanted to be sure that it works (no warnings)
with release. I'm using gcc-4.1 (in release candidate state) in Debian
unstable.
regards,
--
Hasso