ios-xr prefix-list vs prefix-set memory consumption/CPU load

[0x1345]

hi all,

I've just started using ASR9K platform with IOS-XR sw, and was wondering if there is a difference in memory consumption/CPU load if i were to use a prefix-list vs prefix-set.  i understand how to apply/use both.  i would prefer not to have to apply one method and check the stats and then apply the other method and check the stats.  The little we have to tinker with our PE platforms the better.

thanks in advance.

ciao,

Roberto

[xthuijs]

hi roberto,

we had done some benchmarking on that years ago, and the execution time between inline vs sets is minuscule. although there is some difference, like a usec longer on a set, there is no noticable performance difference. this was done btw on an RSP2/ppc so for the new x86 cpu's that usec mentioned is probably nsecs there.

I would recommend using sets btw, this because it is easier to update and manage in case changes are necessary. regardless of the size of prefixes/as's/communities.

note also that when an rpl is configured, it gets compiled and sent to the application/attachpoint. starting xr38 (or so) radix trees were implemented also, making it possible to do signle lookup instead of a walk on a list.

where you'd burn some time is in the way you'd be setting up your regex. for instance this:

ios-regex '_(53864|22651|8114|21146|36743|28563|2217|22636|22409|27631)$',

has the same end result as this list set :

a s-p a th -set 1 0 0 _ ra n d om

ios-regex '_53864$',

ios-regex '_22651$',

ios-regex '_8114$',

ios-regex '_21146$',

ios-regex '_36743$',

ios-regex '_28563$',

ios-regex '_2217$',

ios-regex '_22636$',

ios-regex '_22409$',

ios-regex '_27631$',

or this inline:

if as-path in(ios-regex '_53864$',ios-regex '_22651$',ios-regex '_8114$',ios-regex

'_21146$',ios-regex '_36743$',ios-regex '_28563$',ios-regex '_2217$',ios-regex '_22636$', ios-regex '_22409$',ios-regex '_27631$') then

p a ss

but in the latter 2 cases the regex is fired many more times and that can cause some "performance" when evaluating the prefix.

so using sets is best play, and limit the use of unique regex calls as much as possible by grouping them together.

xander

[0x1345]

thanks Xander for clearing all of this up.

[mivens]

How does the performance in the previous two examples compare to using the native operator ‘as-path originates-from'?

 as-path-set 100_random
 originates-from '53864',
 originates-from '22651',
 originates-from '8114',
 originates-from '36743',
 originates-from '28562',
 originates-from '2217',
 originates-from '22636',
 originates-from '22409',
 originates-from '27631'

Do you still get a performance hit compared to the single ios-regex call:

ios-regex '_(53864|22651|8114|21146|36743|28563|2217|22636|22409|27631)$'

[xthuijs]

the "cost" here is using ios-regex which invokes the regex engine. but since you're doing it single line it is only a one time hit.

but when we say "cost" here, we're talking usec/nsec.

your first option 1 is easier to the eye and manage, at the "cost" of a larger configuration.

so both are fine, the choice really depends on what you prefer.

cheers

xander

[sbhadrav@cisco.com]

The Memory usage analyser tool records brief details about the heap memory usage of all processes on the router in two different snapshot, comparing the results and providing a report highlight processes that are increasing or decreasing their held memory values. The tool is used as follows:

1.    Take an initial snapshot using the following command ‘show mem compare start’
2.    Take another snapshot using the following command ‘show mem compare end’
3.    Print the output using the following command ‘show mem compare report’

The tool could be integrated into a regular operations routine whereby the initial memory report is obtained at the beginning of the shift, the ‘end’ report part-way during the shift allowing time for the engineer to review the report.

The output contains information about each process whose heap memory usage has changed over the test period. It is ordered by the size of the change starting with the process with the largest increase. Again, the most efficient approach to detect memory leaks using the tool, is to use the tool on a stable system with no configuration changes taking place during the monitoring period.
 

For each process the following information is printed:
JID    Process Job ID
Name    Process name
mem before    Heap memory usage at start (in bytes)
mem after    Heap memory usage at end (in bytes)
difference    Difference in heap memory usage (in bytes)
mallocs    Number of unfreed allocations made during test period
restarted    Indicates if the process was restarted during test period