my opinion about jackson: pro: - it's really very mature and proven in lots of projects - in json performance rankings it's most times with the best ones - it can be deployed in OSGi easily and uses semantic versioning - i've used it in several projects and had no problems
contra: - it's quite fat from a deployment perspective, it think at least two bundles are required (core+databind) making ~1.5 MB only for JSON parsing/writing - it does not implement javax.json interface, and does not seem to plan to do this any time soon - we cannot decide to switch to another implementation later - we already invested a good deal of time in javax.json migration i'm wondering if the reason of the performance degradation is: a) poor performance in the johnzon impl itself b) poor usage of the javax.json API on our side in the GET servlet c) design problems with the javax.json interface which makes it problematic to get good performance in performance ranking to be found on the internet johnzon was not tested in most times because it is quite new. i'm not sure how much time the johnzon community has invested in performance optimization yet, and if improvements are expected here any time soon (our patch for making the deployment OSGi compatible is still pending due to lack of time for reviewing/testing it). stefan >-----Original Message----- >From: Carsten Ziegeler [mailto:[email protected]] >Sent: Saturday, April 1, 2017 8:55 AM >To: Sling Developers >Subject: [JSON] Performance problems with new json library > >Hi, > >as you all know we had to replace the usage of the org.json library due >to it's license (see SLING-6679). We decided to go with Apache Johnzon >as the replacement. > >Now as most of the work is done I did some performance testing, mainly >of the json get servlet, rendering a 2k json response requested by 50 >clients in parallel. Unfortunately it seems that this library is causing >a significant performance degradation. I noticed json responses to be >between 15% and 20% slower. I can't explain what is causing this as all >we do is simply write out json. > >So I went ahead and did a quick test by replacing johnson with jackson >and interestingly, this one is in the same range as org.json, slightly >faster even. > >Given this, I seriously think we should not use johnson but switch to >jackson. As we have identified all the places, replacing is not one of >the nicest tasks, but it should be doable within a short time frame. > >WDYT? > >Regards >Carsten >-- >Carsten Ziegeler >Adobe Research Switzerland >[email protected] >
