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

Low performance when working with requests returning higher weight of data #106

Open
piotrtar opened this issue Jan 19, 2023 · 2 comments
Open
Assignees
Labels
help wanted Extra attention is needed needs investigation

Comments

@piotrtar
Copy link

piotrtar commented Jan 19, 2023

I noticed that using the plugin to send get request which responds with JSON of weight 298KB causes Cypress Test Runner to crash later in the test when run headed:
Screenshot 2023-01-19 at 18 41 16

When run headlessly the test lasts 03:10 min:
Screenshot 2023-01-19 at 18 49 53

When changed cy.api() to cy.request() the test lasts 0:30 min:
Screenshot 2023-01-19 at 18 50 20

@filiphric filiphric self-assigned this Jan 25, 2023
@filiphric filiphric added help wanted Extra attention is needed needs investigation labels Jan 25, 2023
@JonathanSTH
Copy link

@filiphric First, thank you for such an awesome plugin! Love using it. Second, I do run into this as well. I'm getting back data at speeds of 7 seconds when using cy.api(). Using cy.request() returns in 630ms. It seems to do with the size of the data. One particular command gets back data with the length of 12,314 items (body.length). Seems to do with actually rendering the actual response data. Perhaps limiting what is shown at first might be an answer? If it is all shown, have an expand that finishes the data?

@glennmicallef
Copy link

glennmicallef commented Aug 25, 2024

@filiphric firstly also thank you for this amazing plugin, it is a pity that I had to disable it for the same reason reported above. I have some tests containing 50 API calls, some of which have pretty big response payloads. When adding this plugin cypress slows down a lot and most of the time it crashes.

I investigated this a little bit and it is clearly a memory consumption issue. Just to give an example, when running a specific spec file I tested with, the Google Chrome Helper (Renderer) process had the following memory consumption when debugging using cypress open:

  • without cy.api(): 1st run - 700-800mb of memory, 2nd run - 700-800mb of memory
  • with cy.api(): 1st run - 3-4GB of memory, 2nd run - 5-7GB of memory and then it crashes!

This could be happening due to a memory leak.

I had a look at the code to try and find out what could be the culprit of this memory consumption and after some trial and error changes I found out that when commenting out the Prism library syntax highlighting here and suddenly the tests where running a lot faster with a lot less memory consumption:

  • with cy.api() without syntax highlighting: 1st run - 1.8-2GB of memory, 2nd run - 2.5GB

So one easy way of significantly lowering the likeliness of this problem is to introduce an option to disable syntax highlighting altogether. It is a nice feature, but I would be more than happy to do without it if it means that I would be able to benefit from the rest of the features of this plugin 😄 - and the result isn't that bad:

Screenshot 2024-08-25 at 18 31 56

2GB of memory is still a bit on the high side when compared to 700-800mb of memory when using cy.request() but at least it would make this plugin useable in scenarios where a lot of API calls with large payloads are needed.

One other factor which might be contributing to memory consumption (haven't tested this) is the fact that a lot of mounting and unmounting of the of the Vue app is happening especially when a test has a lot of API calls (even more with snapshotOnly enabled).

An alterative (and possibly neater) way to approach this (not sure about this as I am not familiar with nuances and limitations of cypress plugins) could be to mount the Vue app once and feed additions to the props data per API call through a redux store (using action dispatches) and the app will reactively update the plugin UI when the store data updates. The same way could be used to avoid unmounting the app in case of snapshotOnly - a redux action could be used to show/hide the app instead of unmounting it.

Hope this helps in solving this issue quicker 😃 - and again thank you for making a lot of E2E engineers' lives a lot simpler with this intuitive plugin.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed needs investigation
Projects
None yet
Development

No branches or pull requests

4 participants