EqualsToJson has bad performance for big json with common keys occuring often

[dongelci]

Description

We have a test setup with recording via proxing in wiremock. Wiremock saves the mappings with equalsToJson pattern.
After upgrading equalsToJson to JsonUnit there is a performance issue for a case. If there are many mappings with big json pattern having many keys in common, then response takes very long time, 40s to 55s. I forked the project and pushed acceptance test in branch gh-2705, see References

This happens only with many keys in common. If keys differ in every mapping, then there is no trouble.

When I revert equalsToJson pattern to previous library, there is no issue, response takes a few seconds.

Since I am not familiar with code base, I couldnt provide a fix in pull request but just acceptance test to reproduce.

Proposal

Old library zjson compares under 1s. The same performance is required.

Timeout value, fixtures or accepysnce value can be refactored according to codin guidelines of wiremock project.

Values and keys in jsons have no meaning due to randomizing the values. You can gladly use own json but using same depth and amount of keys is important.

Reproduction steps

Please run acceptance test to reproduce the error, see References or commit 0e6d6e2.

References

https://github.com/dongelci/wiremock/tree/gh-2705

[leeturner]

Hi, many thanks for taking the time to fork the project and add the test. It is very helpful. Would it be possible to let us know if you are upgrading from one version of WireMock to another where you saw the performance issue so we can try and narrow down where the performance regression might be.

You also mentioned zjson in your issue report. Could you give more information on what zjson is

[dongelci]

Hi @leeturner,

thanks for your feedback.

I mean zjsonpatch. This is a library used before switching to jsonunit. Relevant commit is 7ead912, which was reverted in
ef4cf34 and then reused in 28c5e67.

2.27.2 has no issue. Next release after this is 3.0.0 and there is an issue in it

[tomakehurst]

We switched away from zjsonpatch partly because there were comparison bugs we couldn't resolve with it IIRC.

Since we're dependent on JsonUnit now and the performance issue is presumably within its diff code, maybe it would make sense to raise an issue with that project?

Also, generally I wouldn't recommend using equalToJson for large comparisons. matchesJsonPath is usually much more efficient here, particularly since we introduced some per-request caching that's most effective when you use sub-matchers.