Open schickling opened 6 years ago
I confirm this issue.
To me this happened when I was running a query that was returning a lot of data.
Can everyone share some information when it happened to them? 🙂 This might help pinning down the problem.
This is one potential cause: https://github.com/graphcool/graphql-playground/issues/356.
@marktani the high CPU only occurs with the HTTP middleware. #356 seems to be related to the Electron app
@schickling It happens for me (express middleware).
Can everybody share at least little bit info how to get to this state, because i tried to reproduce it and no luck.
So far I have not been able to reliably reproduce this. Some potential causes
The times I’ve seen it happening I had one or two (max) playgrounds open; I had a few tabs open; some queries may have errored a few times before getting it right. Small schema.
having this issue as well in v1.4.3 Mac version,
at the workplace selection screen, the GraphQL Playground helper is constantly at >20% cpu usage after opening the workplace, cpu usage raised to ~60% after opening schema, my 2015 Macbook Pro started spinning up the fan, cpu usage raised to ~100%
don't blame on electron, I'm using a lot of electron apps like VSCode and GitKraken, all work just fine I highly suspect that someone sneaked in some codes to do mining
@kambing86 No there is no mining you can see it in network tab..
Right, I might have an additional insight on this. I am developing a GraphQL server with graphl-yoga
, so naturally I am using Playground. Locally, I run this server via Lando, so in Docker containers. When Playground goes and uses the CPU at 200+% (it really happened), so does Docker.
I haven't yet checked network traffic etc., to see what's actually going between the two, if anything...
Hi! Beforehand, thanks for this awesome project!
I'm having this issue too, with the electron app. The CPU usage raises only when the app window is visible. I removed locally all the CSS animations and the usage (showing the New Workspace window) dropped from ~30% to ~2%. Removing only the SVG that shows when the application is loading makes a difference on the usage.
I don't have context on the project, but I think this could be one of the main issues.
Yea, i was digging little bit inside and playground is rendering like crazy, even that you are not doing anything. You can see it in performance graph:
Thanks for the insights everyone! We're working on the playground performance and will probably have a new release this or next week with some improvements :)
I can definitely replicate what I wrote in my last comment: as soon as I open PG in Chrome and run a query, the Docker container running the server starts eating 160+% of CPU, and so does PG. If I do what @emibloque said, and just switch tab, the Chrome's CPU usage halves, but the Docker container's one remains the same. The only way to calm the storm is to close the tab where PG is running.
This issue happens to me as well.
OS: macOS High Sierra
Chrome: Version 64.0.3282.167 (Official Build) (64-bit)
Middleware: graphql-yoga
Every time I open the playground the CPU start increasing whatever the size of the schema.
Any news on this, @timsuchanek? This is starting to become a serious issue for me, as it also affects the docker container where Yoga is running, and the machine starts struggling under the excessive CPU usage.
Noticed the same issue on macOS High Sierra after creating a very simple server with graphql-yoga
: shortly after I open the Playground in the latest Chrome my laptop fan starts running. Same thing with the Electron version. Interestingly it doesn't happen with the version hosted at graphqlbin.com.
I think i figured out what is problem, i will try to make fix for it 👍 Yea i got it playground cpu usage varies with number of rendered editors so we can just render active editor to reduce cpu usage :)
@Huvik I'm working on a fix for that, which is also including reducing the number of editors. So no need from your side to work on that :)
Fans start spinning as soon as i open playground in Chrome, (Version 64.0.3282.186) Mac OS High Sierra(10.13.3) Slow down after a while but, can spike out of a sudden. Have many extensions but happens in incognito mode, too.
any update on this? seems like the recent release still suffering, any insight so that we can help to figure out and solve this?
This also happens on the Electron app for me.
There are many elements on the webpage which are animated using CSS animations, even though they are not visible. For example the loading indicator (which is completely covered by the playground and not visible at all, yet continues to play the animation), or the rotating circle inside the URL input box. This causes the browser to continuously repaint large parts of the screen. If you look at the performance inspector, you'll see that no JS is being executed, yet rendering (purple color in the chrome dev tools) eats up almost 100% of the CPU time. If you remove all CSS from the webpage, the CPU usage drops to zero.
Actually, the loading indicator and the invisible rotating circle inside the URL input box are the only two elements which cause the high CPU usage.
Still experiencing very poor performance with latest version on MacOS High Sierra.
Thanks for that breakdown @wereHamster ! I'm right now looking into and will soon have a new release ready where this should be fixed
Thanks for the patience, everybody! I just released a new playground version that should fix these performance issues!
Please let me know if you still have a high cpu usage :)
It's released in the Electron App in version 1.4.5
and in the react app (graphql-playground-react
) in version 1.4.7
the loading icon is the root cause of the performance issue? https://github.com/graphcool/graphql-playground/commit/a5a59707e59dee92576ce91b213f8655bce28b2a
so it seems like the issue went away after this commit, but if I fired a request which took like few seconds, and returns a big and long json, then it became unresponsive and high cpu usage again
to be honest, I'm using another one as my daily driver, and built using old version of electron, but it's butter smooth
https://github.com/andev-software/graphql-ide
I like graphql-playground for the theme, but sorry it's not usable at all
Thanks for the feedback @kambing86 ! Yes, it is correct, that that fix was only related to css issues. We're working on a bigger refactoring at the beginning of this week and will make sure to include your use case with big responses!
@timsuchanek I still get this issue with the latest PG in Yoga.
same here, the playground is pretty much unusable at the moment. I think rendering seems to be the issue as scrolling in a decent size json output is sluggish and not very nice to work with. On large json output (203814 lines), the browser becomes pretty much unresponsive or even gives up. Using something like Altair has no problem, runs the query and the json output in approx 4s and scrolling is smooth. I am using 1.14.1 version of graphql-yoga. Just wondering if this is going to be fixed or should I turn off playground and try and incorporate something else?
Thanks for your comment @iamgmd ! We can't give a clear timeline right now, but it is definitely something we will work on in the coming weeks. After a quick look into Altair I'm pretty sure that we can accomplish the same speed as they're also using Codemirror for the result view.
@iamgmd your comment was so important to use, that we just released a new version of the react and electron app with a performance that matches the performance of the original GraphiQL and Altair 🙂
You can download the latest electron app here: https://github.com/prismagraphql/graphql-playground/releases/tag/v1.5.9
@timsuchanek Middleware express coming soon for Yoga?
Ah m8, that is sweet and I can confirm that it renders much faster and scrolling is smooth on my 203814 line example. Job well done and now very usable :-)
You might be surprised to know I did still manage to break it when running a really really large query (1.6 million lines - 45MB). The result is that the query doesn't display all the lines, only about 3/4 of them and therefore the output is not complete. Altair did manage to display of all the lines but not surprising was sluggish when scrolling. That being said though, it is better to have all the lines whilst sacrificing performance in this use-case.
I think this happens on high volume subscriptions. The results area gets a lot of results and probably the front end code and/or component is not very optimized. I cannot even scroll to told results, yet the whole browser tab becomes unresponsive.
"graphql-yoga": "^1.17.4"
100% cpu usage on just open web app macOs, google chrome
This is still a problem, why is this issue closed? Opening the playground in the browser causes my mac to slow down noticeably even when not running any queries.
Edit: this is with an empty query pane. Literally launching the playground and doing nothing will cause my machine to become laggy.
Same as @freshtonic web playground slows down my mac (using http://localhost:4466 with an empty query pane)
Downloading the app didn't help either:
EDIT I think it has something to do with local development with Docker, when I open a playground that's connected to prisma.io test servers the cpu seems normal?
I think it has something to do with local development with Docker, when I open a playground that's connected to prisma.io test servers the cpu seems normal?
FWIW, I'm not using Docker.
I can confirm that increasing the query refresh interval in the settings works around the issue. But even with the default settings it doesn't seem like something that should slow down my machine significantly.
Yes, it's because of schema pooling. This feature runs only on local from the default you can adjust it in settings by changing schema
option https://github.com/prisma/graphql-playground#properties
Yes, it's because of schema pooling. This feature runs only on local from the default you can adjust it in settings by changing
schema
option https://github.com/prisma/graphql-playground#properties
I have put "schema.polling.enable"
to false
and this seems to fix the issue, at least for me.
Can confirm what @johhansantana said. Disabling polling fixed the CPU issue.
I think this may happen when live reload is ON and doing quick iterations. At least, this was my use case.
Just for refference if someone gets stuck with huge memory consumption. By code first approach it's needed to turn of the polling and the query refresh interval, I wasn't avare of that and my API started to consume more and more memory without an code explanation, simply the polling and refreshing the schema was fault, since it's a reversed approach to development.
E: And Playgrounds requiers almost 250MB of memory more then graphiql, to keep a schema alive?
I have 10 lines of server code, no backing DB, and my macbook fan spins like mad after i open playground in chrome. I have to close it every minute or so, or my machine overheats and crashes.
It's using a lot of GPU. I thought it was a trojan bitcoin miner at first.
@huv1k @johhansantana Disabling schema polling worked! THANK YOU!
Disabling schema polling worked! =)
Maybe It is related https://github.com/prisma-labs/graphql-playground/issues/653#issuecomment-517645196
This issue pertains to:
What OS and OS version are you experiencing the issue(s) on?
MacOS High Sierra
What version of graphql-playground(-electron/-middleware) are you experience the issue(s) on?
v1.3.6 (web)
What is the expected behavior?
The Playground should be friendly to my CPU 🤔
What is the actual behavior?
In some scenarios the CPU goes all crazy (sometimes above 80%). I couldn't exactly pin it down to a specific reproducible case but it's happening quite frequently. I suspect the Playground is "trapped" in some kind of infinite loop.
What steps may we take to reproduce the behavior?
Unfortunately I couldn't yet find a clear way to reproduce it. Would be great if other people can add more information!
Update:
I suspect it has something to do with errors (for example when the server returns an error)