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

High CPU load when many messages occurred in browser console #1356

Open
snemh opened this issue Jul 24, 2019 · 3 comments
Open

High CPU load when many messages occurred in browser console #1356

snemh opened this issue Jul 24, 2019 · 3 comments

Comments

@snemh
Copy link

snemh commented Jul 24, 2019

High CPU load when many messages occurred in browser console. When there is huge number of warnings generated, testem tries to process and print each message in a loop, causing high CPU load which eventually causes the processes to crash.

@kratiahuja
Copy link

kratiahuja commented Jul 24, 2019

@snemh would be good to add a failing test case or reproduction first to show the problem and then we can see how to fix it.

cc: @stefanpenner (Thank you Stef for helping recognizing the root cause)

@stefanpenner
Copy link
Contributor

Concretely, it appears the architecture of message syncing/formating/printing between split_log_panel and scrollable-text-panel is not scalable. These code-paths must operate on the entire message history, so as the number of messages (app warnings) increase, testem slows down (and node/ember CPU time increase) as the message history grows. As observed in @snemh this can quickly lead to a totally locked up process.

In the example @snemh, it looked like we where operating at over 130,000 lines of text.

These code-paths will need to be changed. Although the changes are relatively straight forward, it will take some effort to accomplish them and I don't personally have extra bandwidth to implement. Although I will gladly provide code-review/guidance to those able to do the majority of the work.

@runspired
Copy link
Contributor

Until this is fixed, if you don't care about these logs (I suspect most of us don't) you can free up a lot of memory and cpu by preventing testem from serializing these and emitting them.

<script src="/testem.js" integrity="" data-embroider-ignore></script>
<script type="text/javascript">
	// disable testem log output
	// by default testem serializes all of these logs
	// and transmits them through the websocket even if
	// the reporter is configured to ignore them. This results
	// in extremely high memory and cpu utilization and eventually
	// will crash the console.
	const ignoredLogTypes = new Set(['log', 'warn', 'info', 'group']);
	// restore original functionality
	ignoredLogTypes.forEach((method) => {
		console[method] = Testem.console[method];
	});
</script>

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

4 participants