search

Kong / insomnia

The open-source, cross-platform API client for GraphQL, REST, WebSockets, SSE and gRPC. With Cloud, Local and Git storage.
https://insomnia.rest
Apache License 2.0
34.64k stars 1.96k forks source link

Performance issues #3011

Closed thirstyfish closed 1 month ago

thirstyfish commented 3 years ago

We're experiencing performance issues with Insomnia Core 2020.5.2 on MacOs Mojave (previous Insomnia versions exhibited the same issues) with the Quick Switch modal and environment variables.

We have around 200 GraphQL requests organised into around 80 folders (3 to 4 levels deep).

The Quick Switch modal frequently (but not every time) freezes the application (app needs to be force closed) when trying to search for and switch to another request.

We have around 35 environment variables that are resolved from response body attributes that we use in GraphQL queries and mutations. Even though the trigger behaviour is set to "When expired - resend when existing response has expired" with a max age of 60 seconds, Insomnia seems to be resolving every variable for every request on Send, even if the given request doesn't use the given environment variable. This makes all of our GraphQL requests very very slow when issued from Insomnia.

Environment:

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

AndreMaz commented 2 years ago

Hi @dimitropoulos What is the status on this? Can this issue be solved in near future?

andrasore commented 2 years ago

Hi there, Any update on this?

AndreMaz commented 2 years ago

I'm glad to see that I'm not the only one who wants this to be solved. @develohpanda @DMarby sorry to tag you but can you take a look at this?

oliverjanik commented 2 years ago

I experience similar issue on Win 11 when I flick between windows. When I get back to insomnia 50% of the time I get a freeze that lasts 5 seconds or so.

dimitropoulos commented 2 years ago

apologies for the radio silence. this is something we care about, for sure! we have a few things in the queue ahead of it that are fairly critical, for example upgrading electron and node (which then means big architecture changes such has potentially removing node-libcurl, etc.).

I did, though, just now add a triage ticket to our team's board linking to this issue. I realize that this may sound disingenuous considering this (quite serious!) issue went a full year without being commented on from the team, but this feedback does not fall upon deaf ears -> just busy ears.

The information you provided here is very very helpful, but the absolute best thing would be if you can provide an export of a workspace. I realize it may not be possible to do if there's private information and therefore would require some time to redact any private info from the JSON export: but just wanted to mention it. We'll be trying to recreate something like this, all the same, with the information you provided.

Vyoam commented 2 years ago

I have a reproducible observation specifically regarding delay due to chained requests in base environments. I'm not sure if it can be called a bug or not, but definitely needs to be documented. It is somewhat related to this thread (but I'm not sure how much).

Basically, as a user, I had expected the chained requests (even if defined in base env.) to get triggered only if the request I'm hitting actually needs it. But, the chained requests in base env. run irrespective of whether they are relevant or not. I don't think there's any documentation which highlights this behavior and the timeline tab doesn't give any clue either. So, a user might assume a deeper performance issue with Insomnia.

Obviously, as a user one can try to be meticulous and segregate chained flows to different workspaces. But improvement wise, these are some of my thoughts (all might not be needed)...

For reproducing, use the attached collection (within zip). The base env. has a 'test_delay' variable. And it depends on one of the requests which has an in-built 15sec delay, and is configured as always-resend (Even with that config, intuitively, an average user still wouldn't expect it to trigger for irrelevant cases IMHO). As long as the base env. var. is present, you will have the unnecessary delay when using 'DummyAPI' call. And the delay goes away once you remove the env. var. And as you'd see, that env. var. isn't at all needed by 'DummyAPI'. Insomnia_2022-03-28.zip

LunaticoCR commented 1 year ago

I'm also plagued by performance issues. I think it's definitely related to big collections. I currently have 844 requests, with around 60 variables in the base environment and 19 sub environments with between 2 and 10 variables each. Every time I go into one of the requests it takes several seconds for the request to render variables and tags, and recently if I navigate the UI too quickly the main window goes blank and I would have to restart the app. I really hope this gets looked at soon because I'm at a point where I would soon have to make the hard decision to move to another app, which would be a huge pain, and I really like Insomnia. @dimitropoulos

dimitropoulos commented 1 year ago

hey @LunaticoCR, sorry about your trouble with this. I no longer work for Kong, but the team that does is filled with some great developers and I'm sure they'll take a look at this (performance is one of those things that never really goes away as a concern, you know?).

cwangsmv commented 1 month ago

@thirstyfish since you have 35 environment variables that are resolved from response body attributes that use in GraphQL queries and mutations, can you try to use After-Response Script to save environment variables from the response which will greatly reduce the request render time.

cwangsmv commented 1 month ago

@LunaticoCR we've done some performance improve recently, could you please try the latest version? Besides, if you are also saving a lot of environment variable from response, I suggest to use the After-Response Script to save response body as environment variable which will have great performance improve.

LunaticoCR commented 1 month ago

@cwangsmv I'm currently on version 9.3.3 and I can confirm the performance issues have greatly improved in recent builds. When I started using the app years ago the after-response scripting wasn't available, but I'll absolutely be using it from now on! Thank you!

cwangsmv commented 1 month ago

@cwangsmv I'm currently on version 9.3.3 and I can confirm the performance issues have greatly improved in recent builds. When I started using the app years ago the after-response scripting wasn't available, but I'll absolutely be using it from now on! Thank you!

Thanks for the feedback. Close the issue since it is improved now.