OpenRCA graph structure

[k-jano]

The process of making the final graph structure will take some time. It would be great to held discussion in one issue.

During this process we should pay attention to many available visualization and get the best out of them. Examples shared in this issue will definitly be a good inspiration to OpenRCA final graph.

I want to share with example of Force-Directed Tree from D3.js library. This hierarchial graph captures well network structure and visualize it in very intuitive way. We can easily extract sets of vertices forming a group in a graph.

It would be great to share your ideas and examples of network visualizations!

[k-jano]

During our work we experienced difficulties in using Force-Directed graph type in OpenRCA. Number of nodes and links presented in a graph can be really huge depends on operator infrastructure. Force-Directed tree is very effective form of chart, but may not work in our case. High complexity of Force-Directed algorithm results in comfortable graph usage in case with a very limited number of nodes on average hardware equipment.

One of possibility to get rid off this problem is to take care of limit of visible nodes and links. It can be done in different ways, like display only nodes in one namespace (not whole infrastructure).

I think that we should consider different approach, using more static graph format. One of the interesting examples I found here. In easy way user can display only the part of the analyzed project that interests him. It could have a big impact in improving performance and potentially reach more users.

[bzurkowski]

@k-jano Totally agree!

One of possibility to get rid off this problem is to take care of limit of visible nodes and links.

That's the approach that we will undertake. For instance, present only the service, pod, and node objects initially, and expand other objects (config maps, secrets, replica sets) on demand.

It can be done in different ways, like display only nodes in one namespace (not whole infrastructure).

Yes, we could present a single namespace by default and enable the user to add other namespaces according to needs (multi-namespace selector).

I think that we should consider different approach, using more static graph format. One of the interesting examples I found here.

I like the collapsable graph branches. Please, check out the examples below for more inspiration:

• https://js.cytoscape.org/
• https://cambridge-intelligence.com/

Let's discuss our ideas during the next weekly meeting 😉

[k-jano]

I want to share with some research results. The aim was to optimize the current simulation and consider other approaches.

1. Tree diagrams

• One of the considered approaches involved use of tree diagrams. This is a much more efficient approach than Force Directed graph, especially for a large number of nodes
• Good for hierarchical data, our data only in hierarchical partially
• Multiple parents problem - need to be solved, some solution
  • Using Force Directed Graph
  • Adding extra edges in a graph
  • Using library building up d3.tree

2. Force Directed Graph optimization

• Algorithm complexity of force directed graph is O(nlogn), so it shouldn't be problem with creating a simulation with 10^4 or 10^5 elements
• In every simulation tick all objects position (nodes and edges) are calculating and rendering. I tried to disable rendering in every second tick. The effect was obtaining less smooth simulation and no improvement in visualization for large amounts of objects
• Attempt of number of ticks limitation also didn't improve visualization for large graph and the hard limit did not always guarantee good graph expansion

3. Canvas

• Lagging of simulations can be caused by using SVG elements, possibility of using Canvas instead

4. Force Directed Web Worker

• Idea of hiding graph rendering behind the loader, after graph expansion disabling simulation and browsing static graph

In my opinion we should consider point 3, so far we obtained great simulation with nice feature. If decreasing graph element heaviness is possible, we should try to do it.