Constant high CPU in frontend #5726
Comments
|
Thanks a lot @toupeira, this is very useful information. We do have an animation between changing channels, so maybe it is not being removed properly after the page load. |
|
@karlprieb I have just realised we don't remove the animation for |
|
@engelgabriel Probably will decrease the CPU usage in this view. I will test that :) |
|
Whats about "low client cpus usage mode"? Creating settings in server administration...something like "Disabling all animation, gifs, zoutube videos etc" for slow or old clients PC? |
|
@Abraka since this depends on the client's CPU I think the setting should be per-client as well, and you can already disable most of these individually in the account settings. |
|
I agree, we should have a per user setting for that, disable all animations. We already have the function for that, used on our testing mode. |
|
I removed all unnecessary "load more animations" to decrease CPU usage, but we need to analyze/profile the application to understand why our app increase CPU usage in some views. After that we can create different issues to fix these problems. |
|
Hey, When trying to filter the emoji list I found some delays (also #6636):
I did other tests using the case where a user would be switching to another channel. Switching to a channel with a moderate amount of messages, from the click on the channel name to the finished loading took like 3 seconds (with 1.6s of these being only on one computation and almost all of it in the getRoomDom function) Same as above, but with a few more messages and more loading time to render it. Below there is one from the actual demo.rocket.chat, where the main computation takes 3.6s to render the general channel. I don't feel like this analysis covers all the app, but this cases already show some issues the application is having when rendering common views. One of the problems here is that this rendering times are not due to bad implementation but caused by the technology stack we have here. Perhaps going back to #1680 and looking into some new Library/Framework for the Views could be beneficial in the next steps. @karlprieb let me know if (and how) you feel like this could be improved. |
|
I'm also experiencing (what seems like) excessive CPU usage of constantly ~15% on a MacBook 2016 while RC is idle. In my case I'm using the Electron App v. 2.10.5 with Server v. 0.64.1. Using the internal dev tools I can see 'Recalculating Styles' (with the accompanying Compositing and Paint) events happening approximately every 16ms (which would match up with something rendering at 60 FPS) without any obvious cause. The |
|
@ulope I can confirm this with Chromium 66 after upgrading to Rocket.Chat 0.64.1, the paint events weren't happening previously with 0.62.1 |
toupeira
changed the title
|
Does anyone in this thread notice the same behavior after #12677 was merged (version 0.72.0)? |
|
I'm still seeing a permanent CPU-load of ~15-20% from Rocketchat on version 0.74.3 (Using Rambox or Firefox for displaying the Web Frontend). |
|
@seiichiro0185 May I ask you to record a performance profile on Firefox?
|
|
I did some more investigation. Seems like it is in part dependant on the content. The high CPU-usage of > 15% seems at least in part due to some animated emojis that are used in our Rocketchat Instance. If no animated gifs are displayed on screen I see a lower CPU-usage of around 5% (which is still quite a bit in my opinion for showing Website without any changes). I created 2 performance profiles, one with the gifs in view (rocketchat_gif.txt), and one without (rocketchat.txt). I had to rename .json to .txt, otherwise Github wouldn't let me upload them. rocketchat.txt Edit: FYI a page with just the plain GIFs without any other content does create a CPU-load of ~5% |
|
I was hoping there would be an update here. I am seeing issues of high CPU usage and the web app freezing for a good minute or two pretty regularly. I reported this on #10900 but it looks like this is a similar report that has had more active history. When I look at Chrome's Task Manager, I see this:
It seem to happens when I switch rooms or when I start typing into a room right after switching. I tried to debug -- though it's a bit difficult to do so when it happens at random -- but I did catch it in the profiler once and saw this:
Note that it did not only hang for 9 seconds, but rather I only recorded 9 seconds so that the profiler doesn't crash. It hung for about 60 seconds or so total. When I clicked on the method where it hangs, it took me here:
I hope this helps, as this is an issue that is preventing me from effectively communicating with my team. Sometimes, it's good to take a pause before answering a question, but most of the time, you want to have a quick and free-flowing conversation and it is hard to do if your chat app hangs for minutes at a time. |
|
I think this is no longer an issue :) |
Rocket.Chat Version: 0.49.3
Running Instances: 1
DB Replicaset OpLog: Enabled
Node Version: v4.7.2
Linux version: Debian sid
Firefox version: 50.1.0-1
Chromium version: 55.0.2883.75-5
Certain conversations in Rocket.Chat always hog my CPU (~30% on a quad-core system, distributed across all cores) and cause my fans to start spinning, this can be observed in Firefox using the Performance tab in the Devtools which shows a constant stream of "Recalculate Style" events. After removing one
<style>/<link>tag after the other I think I've narrowed it down to the very first<style>tag in the<head>which has some rules for the.loading-animation. Either removing that<style>tag or running$('.loading-animation').remove()in the console instantly makes my CPU idle again.Not sure why this only happens on certain conversations, I couldn't find any commonalities (I think I've ruled out GIFs, avatars, syntax highlighting, images, file uploads). But since I assume the loading animation is only needed during the initial load, I hope the tag can simply be removed after that's done?
The text was updated successfully, but these errors were encountered: