Spike in CPU usage when iterating over large 'body' object with long timeout. #6944
Labels
type: performance 🏃♀️
Performance related
Comments
|
This is fairly difficult to reproduce on our end without a fully reproducible example of the tests. Can you provide the tests? I would try removing the Can you follow these instructions that will log CPU and memory usage of processes during the Cypress run and share these results also? https://on.cypress.io/troubleshooting#Log-memory-and-CPU-usage |
jennifer-shehane
added
the
stage: needs information
|
Here is the repo. As I suspected, it was not the preprocessor, because the only thing which changed was the defaultCommandTimeout and this is a Cypress thing. cy.get() and cy.visit() as well as listening to routes is a Cypress thing. :) The Logs
The CPU goes up and up and up until it reaches around 180 percent usage and when the wifi turns off, it goes up again to over 400. This is also when the computer gets really warm. Edit: BTW: I updated to Cypress 4.3.0 :) |
|
Setting I think this is due to a few lines in your test, where you are wrapping over the entire body of an iframe and asserting against the body, with the increasing timeout making the issue worse. There shouldn't be a reason to have the I can recreate a spike in CPU using the following code:
<!DOCTYPE html>
<html>
<body>
<iframe src="iframe.html"></iframe>
</body>
</html>
// basically some very large HTMLit("visit example", () => {
cy.visit("index.html")
cy.get("iframe")
.its("0.contentDocument.body").should("not.be.empty")
.then(cy.wrap)
// increase timeout to see issue
.find(".wishlist h6", { timeout: 60000 })
.should("be.visible")
})Without
|
cypress-bot
bot
added
stage: needs investigating
jennifer-shehane
changed the title
@jennifer-shehane why does longer timeout impact CPU usage? I have in some of my e2e cases set to following: I'm also seeing spike in cpu usage in logs then it just hangs: |
cypress-bot
bot
added
stage: backlog
and removed
stage: needs investigating
|
This seems closely related to a bug fixed in 9,2, where unnecessary snapshots were being created while retrying commands. In some browsers this manifested as a memory leak followed by the browser crashing or hanging, while in others in caused an unnecessarily large amount of CPU usage, scaling with the size of the page under test. A more technical discussion of the causes and resolution of the issue can be found in the PR that closed it: I'm going close this issue as resolved in 9.2,0 - if anyone involved is still seeing it after updating to that release, please let me know and I'll reopen. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current behavior:
Cypress interactive mode is trying things out with long timeouts.
CPU usage goes high and computer becomes warm.
Assumptions: Therefore doing too much on my CPU and network and therefore networks turns off.
https://youtu.be/IIpUElTV1Sk (Unlisted video, only you can see it)
When I kill the Cypress process, wifi turns on by itself.
Desired behavior:
Cypress does handle long timeouts.
It does not overflow the system and therefore does not overuse CPU and network, so that nothing turns itself off.
Test code to reproduce
Versions
MacOS 10.15.3
"cypress-cucumber-preprocessor": "^2.0.1",
"cypress": "^4.2.0",
The timeout length is intentionally set:
{ "testFiles": "**/*.feature", "chromeWebSecurity": false, "defaultCommandTimeout": 60000, "video": true }The text was updated successfully, but these errors were encountered: