Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Performance] Application become unresponsive for large JSON #412

Closed
madmax opened this issue Aug 10, 2017 · 14 comments
Closed

[Performance] Application become unresponsive for large JSON #412

madmax opened this issue Aug 10, 2017 · 14 comments

Comments

@madmax
Copy link

madmax commented Aug 10, 2017

Overview

  • Insomnia Version: 5.7.4.933
  • Operating System: 10.13 Beta (17A330h)
  • Summary: When request return very big JSON (2MB) application become unresponsive.

How To Reproduce

When request return very big JSON (2MB) application become unresponsive.

Other Notes

It will be nice to have settings to limit size of JSON that is displayed.

@gschier
Copy link
Contributor

gschier commented Aug 10, 2017

This is an interesting problem because it depends on o the hardware. What kind of computer are you running Insomnia on?

Insomnia does, in fact, implement a size limit but it's currently set to 3MB: https://github.com/getinsomnia/insomnia/blob/develop/app/common/constants.js#L57
Maybe a solution is to lower this default value and let the user increase it via a setting?

@gschier gschier changed the title Application become unresponsive for large JSON [Performance] Application become unresponsive for large JSON Aug 10, 2017
@madmax
Copy link
Author

madmax commented Aug 10, 2017

Macbook pro 2013 8gb i7

@madmax
Copy link
Author

madmax commented Aug 11, 2017

I think the problem is that Insomnia calculate respond size before it is ungziped and my 2.9mb response is actually 45MB response :)

@gschier
Copy link
Contributor

gschier commented Aug 11, 2017

Ah, that's definitely the issue then. I've noticed things start slowing down after around 50MB of JSON on my 2016 Macbook Pro. I guess I should change it to account for the raw size instead.

@madmax
Copy link
Author

madmax commented Aug 11, 2017

I have tested this json (45mb) on Paw app and it work very fast compared to insomnia.

@gschier
Copy link
Contributor

gschier commented Aug 11, 2017

Insomnia wasn't designed to work for responses that large. I might spend some time working on improving this eventually, but it hasn't been a priority so far.

@madmax
Copy link
Author

madmax commented Aug 11, 2017

@gschier perfectly understand it not usual to get so big json. Its probably because Paw use native components not Electron. But it will be nice to have ability to see raw json fast or just not render it in the same thread and block rest of UI (if it is possible).

@gschier
Copy link
Contributor

gschier commented Aug 11, 2017

Totally agree. One day, one day 😄

@madmax
Copy link
Author

madmax commented Aug 11, 2017

@gschier what about fixing limit check on decompressed response?

@gschier
Copy link
Contributor

gschier commented Aug 11, 2017

Ya, I'm releasing the next version of the app today, but I'll make sure that's fixed in the next one 😄

@madmax
Copy link
Author

madmax commented Aug 11, 2017

Currently I downloaded development branch and changed 3mb to 0.5mb :) Its not perfect but application start working again.

@gschier
Copy link
Contributor

gschier commented Aug 11, 2017

Oh ya, sorry about that. If you want, you can also delete the individual response file(s) manually. On Mac, responses are stored in $HOME/Library/Application\ Support/Insomnia/responses/

@iquirino
Copy link

I'm having the same issue on v6.3.2
But with a image as the response.

The application crashed at the first time and continues crashing when i open it.

Where is this path for Windows?

Thank you!

@gschier
Copy link
Contributor

gschier commented Mar 7, 2019

Should be in the %APPDATA% directory I think @iquirino

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants