[JSON] Performance problems with new json library

[Carsten Ziegeler <cz...@apache.org>]

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
cziegeler@apache.org

Re: [JSON] Performance problems with new json library

[Robert Munteanu <ro...@apache.org>]

On Mon, 2017-04-03 at 11:12 +0200, Karl Pauls wrote:
> On Mon, Apr 3, 2017 at 9:59 AM, Robert Munteanu <ro...@apache.org>
> wrote:
> > On Sat, 2017-04-01 at 18:16 +0200, Karl Pauls wrote:
> > > I think we should just switch to xml and be done with it.
> > 
> > I don't think we can drop JSON in the foreseeable future. Clients
> > may
> > choose to switch to XML, but we need to offer comparable
> > performance
> > for those using JSON.
> 
> Not on the first of April. We are free to drop whatever functionality
> on that date ;-)


Indeed we are :-)

Robert

> 
> regards,
> 
> Karl
> 
> > Robert
> > 
> > > 
> > > regards,
> > > 
> > > Karl
> > > 
> > > On Saturday, April 1, 2017, Carsten Ziegeler <cziegeler@apache.or
> > > g>
> > > wrote:
> > > 
> > > > 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
> > > > cziegeler@apache.org <javascript:;>
> > > > 
> > > > 
> > > 
> > > 
> 
> 
> 

Re: [JSON] Performance problems with new json library

[Karl Pauls <ka...@gmail.com>]

On Mon, Apr 3, 2017 at 9:59 AM, Robert Munteanu <ro...@apache.org> wrote:
> On Sat, 2017-04-01 at 18:16 +0200, Karl Pauls wrote:
>> I think we should just switch to xml and be done with it.
>
> I don't think we can drop JSON in the foreseeable future. Clients may
> choose to switch to XML, but we need to offer comparable performance
> for those using JSON.

Not on the first of April. We are free to drop whatever functionality
on that date ;-)

regards,

Karl

> Robert
>
>>
>> regards,
>>
>> Karl
>>
>> On Saturday, April 1, 2017, Carsten Ziegeler <cz...@apache.org>
>> wrote:
>>
>> > 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
>> > cziegeler@apache.org <javascript:;>
>> >
>> >
>>
>>
>



-- 
Karl Pauls
karlpauls@gmail.com

Re: [JSON] Performance problems with new json library

[Robert Munteanu <ro...@apache.org>]

On Sat, 2017-04-01 at 18:16 +0200, Karl Pauls wrote:
> I think we should just switch to xml and be done with it.

I don't think we can drop JSON in the foreseeable future. Clients may
choose to switch to XML, but we need to offer comparable performance
for those using JSON.

Robert

> 
> regards,
> 
> Karl
> 
> On Saturday, April 1, 2017, Carsten Ziegeler <cz...@apache.org>
> wrote:
> 
> > 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
> > cziegeler@apache.org <javascript:;>
> > 
> > 
> 
> 

Re: [JSON] Performance problems with new json library

[Karl Pauls <ka...@gmail.com>]

I think we should just switch to xml and be done with it.

regards,

Karl

On Saturday, April 1, 2017, Carsten Ziegeler <cz...@apache.org> wrote:

> 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
> cziegeler@apache.org <javascript:;>
>
>

-- 
Karl Pauls
karlpauls@gmail.com

Re: [JSON] Performance problems with new json library

[Carsten Ziegeler <cz...@apache.org>]

It's very unfortunate that the 1st of April was on a Saturday...

Carsten

Carsten Ziegeler wrote
> 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
cziegeler@apache.org

Re: [JSON] Performance problems with new json library

[Robert Munteanu <ro...@apache.org>]

On Sat, 2017-04-01 at 08:55 +0200, Carsten Ziegeler wrote:
> 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.

Would it be worth capturing a profiler snapshot and sending it to the
Johnzon project?

Robert

> 
> 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

Re: [JSON] Performance problems with new json library

[Karl Pauls <ka...@gmail.com>]

You might want to check the date of the original message from Carsten :-).

regards,

Karl

On Mon, Apr 3, 2017 at 4:39 PM, Ian Boston <ia...@gmail.com> wrote:
> Did anyone consider gson?
>  Iirc it dosnt have dependencies, is similar in nature to Json.org and is
> the same or quicker.
>
> Best regards
> Ian
>
> On 3 Apr 2017 10:02 am, "Stefan Seifert" <ss...@pro-vision.de> wrote:
>
>> 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:cziegeler@apache.org]
>> >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
>> >cziegeler@apache.org
>> >
>>
>>



-- 
Karl Pauls
karlpauls@gmail.com

RE: [JSON] Performance problems with new json library

[Ian Boston <ia...@gmail.com>]

Did anyone consider gson?
 Iirc it dosnt have dependencies, is similar in nature to Json.org and is
the same or quicker.

Best regards
Ian

On 3 Apr 2017 10:02 am, "Stefan Seifert" <ss...@pro-vision.de> wrote:

> 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:cziegeler@apache.org]
> >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
> >cziegeler@apache.org
> >
>
>

RE: [JSON] Performance problems with new json library

[Stefan Seifert <ss...@pro-vision.de>]

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:cziegeler@apache.org]
>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
>cziegeler@apache.org
>