You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sub-quadratic decreasing of throughput when length of the JSON object is increasing
On contemporary CPUs parsing of such JSON object with an additional field that has of 1000000 decimal digits (~1Mb) can took more than 14 seconds:
[info] REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
[info] why the numbers are the way they are. Use profilers (see -prof, -lprof), design factorial
[info] experiments, perform baseline and negative tests that provide experimental control, make sure
[info] the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
[info] Do not assume the numbers tell you what you want them to tell.
[info] Benchmark (size) Mode Cnt Score Error Units
[info] ExtractFieldsBenchmark.readSpray 1 thrpt 5 2295616.947 ± 156189.629 ops/s
[info] ExtractFieldsBenchmark.readSpray 10 thrpt 5 2259250.907 ± 73227.696 ops/s
[info] ExtractFieldsBenchmark.readSpray 100 thrpt 5 604608.260 ± 2896.206 ops/s
[info] ExtractFieldsBenchmark.readSpray 1000 thrpt 5 36803.177 ± 2190.794 ops/s
[info] ExtractFieldsBenchmark.readSpray 10000 thrpt 5 558.418 ± 32.686 ops/s
[info] ExtractFieldsBenchmark.readSpray 100000 thrpt 5 6.466 ± 0.199 ops/s
[info] ExtractFieldsBenchmark.readSpray 1000000 thrpt 5 0.071 ± 0.004 ops/s
…#278
BigInteger/BigDecimal seems to have approx. quadratic runtime for instantiating big numbers
from Strings. Lacking a better solution we introduce a character limit for
numbers. According to the benchmarks from spray#278, at 100 digits the constant/linear
parts still predominate over the quadratic slowdowns seen with 10000+ digits.
jrudolph
changed the title
Denial of service when parsing a JSON object with an unexpected field that has a big number
CVE-2018-18853 Denial of service when parsing a JSON object with an unexpected field that has a big number
Nov 7, 2018
jrudolph
added a commit
to jrudolph/spray-json
that referenced
this issue
Nov 7, 2018
…#278
BigInteger/BigDecimal seems to have approx. quadratic runtime for instantiating big numbers
from Strings. Lacking a better solution we introduce a character limit for
numbers. According to the benchmarks from spray#278, at 100 digits the constant/linear
parts still predominate over the quadratic slowdowns seen with 10000+ digits.
Sub-quadratic decreasing of throughput when length of the JSON object is increasing
On contemporary CPUs parsing of such JSON object with an additional field that has of 1000000 decimal digits (~1Mb) can took more than 14 seconds:
Reproducible Test Case
To run that benchmarks on your JDK:
sbt
and/or ensure that it already installed properly:jsoniter-scala
repo:The text was updated successfully, but these errors were encountered: