[j-nsp] MX RE how fast is slow

[Saku Ytti]

On (2011-09-08 12:41 +0100), Mike Williams wrote:

> I ask because we find the MX80 slow, really slow.
> As we've got 2 distinctly different traffic types, and 2 distinctly different 
> upstreams (1Gbps and 10Gbps), we're using a rib group and policy to populate 
> 2 additional ribs with different local preferences applied to the learnt 
> routes. Filters direct packets to the right table.
> It'll take the RE a good 10-15 minutes to churn through that job, and that's a 
> bit annoying when you make a small change to a unrelated policy!
> Now, is that us being stupid, or the RE being slow? I know what I'd like to 
> hear :)

I think this is entirely possible, with large enough config it can take over 1h
just to boot up the box and I've seen very long commit times too in lab.
However for most people very very large configs are not going to be real-life.

Even after you remove the large configs, it'll continue to be extremely slow to
commit, until you pop in shell and remove all the traces for the config files
(dunno really why this helps, maybe it's copying the config files when rotating
instead of renaming, still it is SSD so dunno why filesystem would be
bottleneck, but I did this all the time in lab, as it made my labbing so much
faster)

I think the whole commit process is just very unoptimized as there hasn't been
any need to be concerned of its performance.  Hopefully there will be some
focus to make it snappier and maybe when MX80 gets SMP support it'll also help
with the situation (although hard to see why it would help, as it appears not
to be CPU bound)

I never bothered to ktrace to see what exactly is taking time during long
commits, if you have time for this, might be interesting.

-- 
  ++ytti