Optimize json encoding

[philippthun]

While looking at the performance of the /v3/security_groups endpoints (PR #2475), I also checked how much the database queries were contributing to the overall response times. As this was not much after optimizing the queries, I started to look into the topic of JSON serialization. I found several comments and benchmarks claiming that Oj is the fastest JSON encoder/decoder; so I started with a small PoC.

I've managed to completely switch to Oj and run all unit tests successfully. For comparison of JSON outputs before and after the change, I use the jd command-line tool.

I decided to introduce an optional config property (use_optimized_json_encoder). I've enabled it on a foundation and successfully run CATS.

Here are some results of locally executed performance tests (X-Runtime header):

	GET /v3/security_groups?per_page=500 as admin *	GET /v3/security_groups/:guid as regular user
baseline	19.802s	0.195s
PR #2255	5.520s	0.158s
PR #2475	3.492s	0.029s
this PR	2.506s	0.025s

* each security group is assigned to 500 spaces

• I have reviewed the contributing guide

• I have viewed, signed, and submitted the Contributor License Agreement

• I have made this pull request to the main branch

• I have run all the unit tests using bundle exec rake

• I have run CF Acceptance Tests *

* We cannot run all CATS on our foundations as we do not enable all CF features, but all the executed tests were successful:

Ran 136 of 216 Specs
SUCCESS! -- 136 Passed | 0 Failed | 3 Pending | 77 Skipped

[JenGoldstrich]

Hey @philippthun,

Thanks for the PR!

Oj seems actively maintained so that sounds good, one thing I did notice is that this PR introduces another gem rspec-json_expectations which seems to not be actively maintained based on the last commit being from two years ago and this comment from May 2021 attempting to reach out to maintainers. I think we should continue to use .includes json-sub-string or switch to a more actively maintained JSON library.

[philippthun]

Hi @JenGoldstrich! Thanks for your review. The rspec-json_expectations gem is indeed not really needed. I've removed it from the PR and adapted the tests.

[tjvman]

@philippthun Are you planning to make a PR to capi-release to add the new config property?

[philippthun]

@tjvman I'm not sure about this. Ideally using the optimized json encoder should become the default. It might make sense to add the config option also to CAPI and then enable it on some foundations to see if everything is really compatible. And in the end this option could then be removed again...

[tjvman]

@philippthun Yeah, that makes sense to me for this kind of performance optimization thing - make it an opt-in at first, then make it the default. How long (time or number of releases) do you think we should leave it as optional

I don't see a way to enable the use_optimized_json_encoder besides editing the config via ssh after deploying, but I might be missing something. Assuming I'm not, then the option should be exposed in capi-release - otherwise it doesn't make sense to have it be a configurable thing (don't want to encourage users to live-edit the CC config)

[philippthun]

@tjvman I've create a CAPI PR (cloudfoundry/capi-release#208) that exposes the use_optimized_json_encoder config property as experimental.

I guess we would enable it stepwise on our foundations, so the property might stay there for a few months.

[Gerg]

I think this is a great change and should provide API-wide performance improvements!