Tests with many network requests are slower in 6.7+ since logging of all intercepts
be-hel opened this issue · 8 comments
What would you like?
I would like to exclude some network requests from Cypress since cypress processing is not fast ennough for high performing applications. The response time is so slow that it both can make the tests flaky and also the test execution time is too long. A simple solution would e.g. by adding some config where I can list the requests I want to bypass Cypress processing.
Why is this needed?
As cypress has evolved processing requests have become slower, which is the natural cost of enabling more features in Cypress. See example for various cypress versions below.
Test page:
<!DOCTYPE html><html> <head> <title>Slow Loading</title>
<script>
(async() => {
let startTime = performance.now();
for (let i = 0; i < 100; i++) {
await fetch('webclient/test.jpg');
}
const nonParallellResult = performance.now() - startTime;
document.getElementById('header').innerText = 'Fetching in parallell...';
startTime = performance.now();
const createRunner = () => new Promise(async (res, _) => {
for (let i = 0; i < 100; i++) {
await fetch('webclient/test.jpg');
}
res();
});
const inParallell = 5;
const runners = [];
for (let i = 0; i < inParallell; i++) {
runners.push(createRunner());
}
await Promise.all(runners);
const parallellResult = performance.now() - startTime;
document.getElementById('header').innerText = `Done, fetch 100 in sequence in ${nonParallellResult} ms and 500 in parallell in ${parallellResult} ms`;
})();
</script></head>
<body><h1 id='header'>Fetching one at a time...</h1></body>
</html>The result is the following when loading the test page in various versions of cypress (test.jpg is 415 kB):
8.7.0: Done, fetch 100 in sequence in 1992.800000011921 ms and 500 in parallell in 7448.199999988079 ms
7.6.0: Done, fetch 100 in sequence in 1470.2999999523163 ms and 500 in parallell in 6233.800000011921 ms
7.5.0: Done, fetch 100 in sequence in 1301 ms and 500 in parallell in 4818.800000011921 ms
6.7.0: Done, fetch 100 in sequence in 948.8000000119209 ms and 500 in parallell in 4337.900000035763 ms
Other
This is related to #8156. If that issue is fixed there may be no need for the abilty to exclude requests.
Thanks for providing a reproducible example to track down perf issues. We have some reports of this, but often there isn't a narrowed down version of the issue for us to verify.
Yes, that is planned work for the future, but I think that addressing the performance of logs is something we should look into also. Someone may wish to see 100s of logs and this should be performant as well.
We are also experiencing this issue - tests are flaky with long execution time which means we can't upgrade before this issue is solved.
You can now turn off logging for requests by passing log: false through cy.intercept() as shown in this doc. This could help with any performance issues of logging multiple requests.
@jennifer-shehane I didn't know that this option would help with performance issues but according to #26069 the log cannot be deactivated if an interceptor function is used. If the performance benefit proves to be measurable, I'd highly appreciate prioritizing the other ticket