[Xorp-users] Why Xorp so slow ?

[Bruce Simpson]

Sébastien Namèche wrote:
> ...
> last pid:  1055;  load averages:  1.44,  0.82,  0.40    up 0+00:13:38   
> 13:53:40
> 24 processes:  2 running, 22 sleeping
> CPU: 88.3% user,  0.0% nice, 10.5% system,  1.2% interrupt,  0.0% idle
> Mem: 74M Active, 21M Inact, 29M Wired, 252K Cache, 11M Buf, 1372M Free
> Swap: 3039M Total, 3039M Free
>
>    PID USERNAME  THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
>    545 root        1 103    0 47044K 44152K RUN      1:36 32.96%  
> xorp_bgp
>    451 root        1  59    0 15424K 10676K select   0:58 22.17%  
> xorp_fea
>    512 root        1  59    0 19268K 15924K select   0:51 18.26%  
> xorp_rib
>   

P.S. I should point out that we're well aware, as developers, of the 
contention on the BGP-RIB-FEA path. It's in my gunsights right now! But 
doing something about it is not going to happen overnight and we need 
all the help we can get.

    Again, this is nothing to be alarmed about -- the default 
configuration of XORP in the community branch is going to use TCP 
sockets out of the box for the IPC transport.  This means lots of 
kernel-userland context switches. Using shared memory or pipes might 
help, however, this requires digging a little deeper into the code to 
see where the performance switches are.
    XORP's focus has been correctness and stability, rather than 
performance, so we have been more conservative about what we point users 
at in the documentation in terms of configuration switches.

    Performance optimization does however require a severe re-think of 
the architecture, and this is what I have on the table right now with 
XORP, Inc. -- I'm proposing that we rewrite a lot of the core XRL layer 
for a start. As this is an infrastructural project, it seems best that 
it takes place in the open.

    We're hamstrung in what we can do until the community branch 
re-opens for development, and this depends on legal clearance within 
XORP, Inc.
    But when the branch does re-open, any and all help will be very 
welcome -- *especially* if you or others have strong C++ and Boost 
background.

thanks,
BMS