jarrodek / ChromeRestClient

ARC Chrome is deprecated. Please move to https://github.com/advanced-rest-client/arc-electron/
Apache License 2.0
370 stars 98 forks source link

JSON view not loading promptly #913

Open ameissnersofi opened 7 years ago

ameissnersofi commented 7 years ago

After making an API call - I receive a 200 and can view the json in the Raw panel. The JSON panel fails to load the result and just spins for longer than is normal

Expected outcome

The JSON pane should work as it has before

Actual outcome

Spinning material design wheel of death for several minutes

Versions

App: 8.19.60.296-stable Chrome: 54.0.2840.98 Platform: Mac OS X (10_12_1)

Steps to reproduce

  1. Make an API call to any JSON returning service
  2. RAW pane loads immediately
  3. JSON pane takes a very long time to load (longer than 3min)
jarrodek commented 7 years ago

Hi,

When you check response headers you'll notice either missing content type header or invalid its value (not a json type). So in this case the app is showing formatting as directed by server or default one. If you are the one operating server just change content type to application/json or contact server admin about the issue. Note that any other client will behave in similar way as the app. Servers are obligated to send proper content type headers.

I'm closing this as WAI.

ameissnersofi commented 7 years ago

No - that's not the case. Content-Type is set to application/json on the response headers. Again, the Raw pane immediately returns the json so the server is doing just fine. The JSON view pane will eventually load and display the JSON, but it takes longer than 3 minutes.

screen shot 2016-12-01 at 9 58 52 am screen shot 2016-12-01 at 9 59 48 am

The JSON pane has some nice feature that I use on a daily basis, so it would be nice if it went back to parsing / loading / displaying promptly.

jarrodek commented 7 years ago

I'm sorry. I didn't understand correctly.

It has to be a huge JSON response then. RAW tab just displays response text so there's just as little work. But JSON parser is a big deal comparing to raw. Because the work is done in the web worker, it waits until whole JSON structure is parsed and decorated with HTML markup. When there's a lot of data it may takes some time. But I never encountered time over a few seconds.

Is there a chance to give me a sample of the JSON output so I can run test on my local machine?

ameissnersofi commented 7 years ago

For this one in particular it is rather large. But, in previous versions of ARC I've made this exact http call and the JSON parser has been very quick to parse and display. It's only been recently that this has been significantly slower than usual.

quicker-response-export.txt slow-response-export.txt

I've attached two response exports for you. One of them causes ARC to take upwards of 3 minutes to parse (600-650 small objects in a single array) while the "quick-response-export" file is part of a paginated response, and thus only contains 100 elements in the array.

The quicker one takes maybe a couple of seconds to display, while again, the larger response takes much longer.

Thanks for re-opening!

jarrodek commented 7 years ago

Thank you for the sample. I'll test it as soon as I finish another issue :)

jarrodek commented 7 years ago

This is result of my test:

slow-response-export.json

run time (ms)
1 204.59000000000015
2 98.07499999999982
3 96.1349999999984
4 99.04500000000007
5 110.92000000000007
6 101.31500000000051
7 98.34499999999753
8 100.46000000000276
9 103.14000000000306
10 107.66000000000349

quicker-response-export.json

run time (ms)
1 358.5100000000002
2 264.244999999999
3 246.79000000000087
4 237.84999999999127
5 231.60499999999593
6 228.38999999999942
7 230.14499999998952
8 240.52999999999884
9 237.11000000000058
10 239.24499999999534

So I started wondering if adding a HTML content to the viewer could be a problem here. The JSON viewer uses innerHTML which seems to be the fastest way to insert HTML content. I've created this test case to check which method is the fastest: https://jsperf.com/innerhtml-and-createelement2 (personally I was counting on document fragment).

This means that the app is using fastest possible way to insert parsed HTML data (meaning the JSON surrounded with HTML markup).

Giving the times I can't confirm or reproduce the issue. I do however still try to find a more efficient way to parse and highlight the JSON structure. Maybe this will help.

ameissnersofi commented 7 years ago

I might be misunderstanding, but I don't think there's any HTML markup in either of the samples I sent. It's just a pure JSON response from the server.

It's also odd that you can't reproduce the issue. All my co-workers have the same issue as I do. We know it's not network related because running curls or using Postman returns the JSON immediately. Again, so does the RAW viewing pane in ARC - it responds immediately - it's just the JSON view pane.

I'm not really sure where else to go from here. :( I don't know why of the two samples I sent you, the larger dataset performed in a third of the time than the smaller dataset. That just baffles me.

I appreciate your looking into this.

jarrodek commented 7 years ago

Sure, I'm not dismissing the issue. I just couldn't reproduce the problem right now. I'll try on other OSs and maybe there I'll be able to reproduce this. I'll let you know as soon as I find anything.