[YANGTOOLS-483] Performance bottleneck Created: 31/Jul/15  Updated: 10/Apr/22  Resolved: 17/Aug/15

Status: Resolved
Project: yangtools
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Mina Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All

Attachments: PNG File ODL_Yangtools_Topology.png    
External issue ID: 4075

 Description   

I opened the topology restconf url in the browser and created 10 services on 2 nodes. Running against the Helium release, I can see so many invocation calls to the topology while profiling.

Please see attached for the profiling snapshots.

 Comments   
Comment by Mina [ 31/Jul/15 ]

Attachment ODL_Yangtools_Topology.png has been added with description: Topology

Comment by Martin Ciglan [ 03/Aug/15 ]

Hi Mina

Please refer to Lithium build. Thank you very much.

Martin

Comment by Tony Tkacik [ 03/Aug/15 ]

Hi Mina, do not see why this is bug, time you see is spent actually serializing out data you requested - serialization of data actually takes only 0.5 % of time, so I do not see this as a problem.

What is your expected behaviour, what are you expecting to change? Otherwise I will close this as Resolved-Invalid - since "inventory" is not YANGTools issue
and bug description + attachments does not provide enough context to determine issue.

Comment by Mina [ 04/Aug/15 ]

(In reply to Tony Tkacik from comment #2)

The reason it is logged against YangTools is the significant increase in the invocation calls when yangtools are called!

Why one invocation call should go beyond 200 calls?

Comment by Tony Tkacik [ 17/Aug/15 ]

Call to process / write / read for each XML / JSON element - there were around 200 elements in one list (probably flow list).

So given that you were serializing / deserializing 200 flows, 200 invocations makes sense. Closing it as INVALID.

Generated at Wed Feb 07 20:53:23 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.