Performance Question

[owengalenjones]

Hello, I have a large number of schemas linked by $ref 's with a combined disk size 1380KB and an object is 675B. In benchmarks it consistently takes around 1.4 seconds to validate the object. Is this an expected time? We were hoping to validate objects at runtime during client requests but this would make that impossible.

Are there any steps I can take to attempt to increase performance here?

Thanks!

[erosb]

Hello @owengalenjones , I can't advise on that based on this information. You can

• check if your schema has any large-scale "oneOf" applicator and if yes, if it is substitutable by an "anyOf" without loosing any guarantees. (this can work because "anyOf" is short-circuit evaluated, unlike "oneOf")
• check with a profiler where is the most time spent
• compare the performance with other validator implementations

[owengalenjones]

@erosb thanks for the reply!

1. The schema I'm testing with is not failing so I would imagine short-circuiting wouldn't gain me anything?
2. I will check
3. So far this is the quickest of the validators I have examined, networknt/json-schema-validator took 9 seconds for the same validation 😨 but I guess I can try some of the others.

[owengalenjones]

As far as profiling, I'm not sure if it shows me anything:

I assume this is just standard recursive call stacks?

I ran the test 3 times to get data for profiling.

Hotspots:

[owengalenjones]

Is that correct in showing that most of the actual time is spent constructing exceptions?

[erosb]

Yes, there can be many ValidationExceptions thrown, if there are many subschema mismatches during validation. But I can't see InternalValidationException on the screenshots. Is it because its self-time is low, or do you use an old version of the library?

[owengalenjones]

Surprisingly with the case of the exceptions, I see no validation error messages when validation is complete. I am running tests of the schema against a sample JSON object that is valid / conforming to the schema.

We are using:

    <dependency>
      <groupId>com.github.erosb</groupId>
      <artifactId>everit-json-schema</artifactId>
      <version>1.9.2</version>
    </dependency>

[owengalenjones]

Ah I see that's slightly out of date. With 1.14.1 the same run is down to ~700ms.

[erosb]

Good. You may profile again, maybe there is a little chance to improve it. I will get back to this issue tomorrow.

…

On Wed, Aug 31, 2022, 23:21 Owen Galen Jones ***@***.***> wrote: Ah I see that's slightly out of date. With 1.14.1 the same run is down to ~700ms. — Reply to this email directly, view it on GitHub <#469 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACCWBSMPDELJYOTL7HMSJDV37EGNANCNFSM6AAAAAAQBQ35HY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[owengalenjones]

Thanks for your assistance @erosb, despite the increase I'm still wondering if there is anything that my profile shows as a potential site of further improvment?

I'm not sure what would be expected or if there is anything that leaps out to you.

In testing the same collection of schemas and the JSON object with the node library Ajv, it only takes 40 ms.

[erosb]

Hello, my last guess: was the JVM warmed up? How many iterations of validation did you run?