Hello !
I have a load test against my Graphhopper profiles, and I saw that just changing speeds and distance_influence parameters (from fastest to shortest) the perform degrades. All my profiles are in CH hierarchy mode. How is it possible? I thought everything was pre-calculated with CH, so it shoudn’t affect in performance no?
Do you have an entry for all profiles under profiles_ch in the config.yml?
What do you mean with “perform degrades”? How much slower are the responses with those profiles?
Basically, I have a script (Gatling Load Test framework) that simulates ramps during a period of time, and then I get p95, p90, p99 etc…these metrics degrade since I have changed from fastest to shortest (changing the distance_influence). I didn’t change nothing in the test script, the only change is on the Map profiles.
About your question…yes…I have the section profiles_ch: for every profile under the section profile:
So, I understand then…that passing from fastest to shortest should not impact in performance.
Before I had a p95 of 223 ms and now 398 ms
So, I understand then…that passing from fastest to shortest should not impact in performance.
That’s not what I said 
There can be a difference. The question is also how you changed the distance_influence and how large the slow down is. If you can find out the exact routes that cause the slow down (or if all routes are slower then pick any route) then you can look into the JSON response under “visited_nodes” and compare them. It is expected that e.g. when the visited_nodes double the response times doubles, but it shouldn’t be much worse.
Ah nice, I am going to look into to that 
, thanks
Just one more comment…that means, that the CH hierarchy doesn’t compact soo much the data structure (shortcuts) like the fastest probably no? So it needs to explore more nodes
CH performance depends on the graphs weights which are affected by distance_influence, that’s expected. You could take a look at the number of shortcuts for the two profiles. It should be different. If your are really keen you could try experimenting with some of the contraction parameters. The defaults do not necessarily work best for all profiles.
The first thing I would try would be increasing prepare.ch.node/edge.max_poll_factor_heuristic from 5 to maybe up to 100. Then maybe try prepare.ch.node.original_edge_count_weight between 1 and 10 or prepare.ch.edge.hierarchy_depth_weight between 5 and 100 (depending on your profile using turn costs or not, if it is using turn costs you need to use the edge-based parameters otherwise the ones I mentioned for node-based contraction). If you do this please feel free to share your results.