Just for completeness, I did some tests with and without the
JSON parser C extension . There's no significant gain (at
this point), maybe when we add the port groups it's more
noticeable though. Average time without it's been 2.09s
while with the C extension it's been 2.03s.
@Han, I can try rebase the patch if you want but that was
basically renaming the Address_Set table and from Ben's
comment, it may be better to keep the name. Not sure,
however, how we can proceed to address Lucas' points in
On Fri, Feb 16, 2018 at 6:33 PM, Han Zhou <zhou...@gmail.com> wrote:
> Hi Daniel,
> Thanks for the detailed profiling!
> On Fri, Feb 16, 2018 at 6:50 AM, Daniel Alvarez Sanchez <
> dalva...@redhat.com> wrote:
> > About the duplicated processing of the update2 messages, I've verified
> that those are not always present. I've isolated the scenario further and
> did tcpdump and debugging on the exact process which is sending
> the'transact' command and I see no update2 processing duplicates. Among the
> rest of the workers, one of them is always getting them duplicated while
> the rest don't I don't know why.
> > However, the 'modify' in the LS table for updating the acls set is the
> one always taking 2-3 seconds on this load.
> I think this explains why the time spent grows linearly with number of
> lports. Each lport has its own ACLs added to same LS, so the acl column in
> the row gets bigger and bigger. It is likely that the port group
> optimization would solve this problem.
discuss mailing list