I’ve been noticing that the page becomes unresponsive when the visualization tab is open when we are dealing with a lot of data. Switching between tabs sometimes is absolutely not possible. I tested with just Looker open on my Chrome browser and noticed that Chrome was hogging the CPU. Is anyone experiencing the same?
I have dashboards ( yes, with multiple visualizations) that routinely kill CPU up to 100%. Interesting we noted that certain column visualizations (grouped i think?) are particularly bad.
As a bit of an aside, I have noticed that Chrome likes to consume as much as my machine will give it, both when I’m using Looker and when I’m not. I’d be curious if the same visualizations perform better on a different browser (if so, I’ll make sure to get word to our product and engineering folks).
That said, some “busy” visualizations can get expensive. We are currently investigating ways to make such visualizations lighter weight, but we don’t have any tangible slated to be released in the near term.
I’ve also noticed that with some large dashboards that our users create with long running (30 second+) queries, it can cause the entire Looker instance to hang and be unresponsive when loading.
This is even the case when we have a per-user query throttle of 2.
I can try Safari or Firefox (I prefer Chrome better and I’m aware of the notorious Google Chrome Helper) and keep you posted on how things go. But if the problem still exists, then Looker won’t be a desirable choice for complex reports.
Yeah, I prefer Chrome myself, but I would be curious how others work for you. In general, your best bet would probably be to try reducing the row limit on the query in question, grouping differently, or plot in a way that that requires rendering fewer data points. At least for the immediate term, the idea would be to reduce the amount of rendered points while we investigate.
I’ve started using Safari and things are not getting much better. A simple query takes ~5 seconds. The whole point of using Looker is to derive meaningful conclusions from huge amounts of data. IMHO recommending us to reduce the row limit or using fewer data points doesn’t make sense. Here is a sample query: Looks like the js is taking around 2.17s. Hope this helps.
Thanks for the info @anbu, I’ll make sure our engineering folks see the network tab in the screenshot above.
Any solution for this issue as we are getting same issue with Look (not even dashboard) and it has 12 dimensions and 5000 rows. I tried other browsers and it’s a same issue. I am using Looker version 4.10.11 and Backend as Google Bigquery. Google BQ UI returns data fast without issue to the browser so I believe Looker is doing some additional process here that is causing this.
Can confirm this issue here as well, always kicks in when you use more than 5 dimensions/measures and > ~500 rows (viz tab is collapsed). If it helps I can record this behaviour and also show as comparison the result gathering in some IDE (e.g. DataGrip)
Hey @kshah7 and @sisu_frank_kutzey . It would be great if you could send an email to help.looker.com with your specific issue, instance information and any additional info so we can take a closer look!
Any updates regarding this? Trying to build a comprehensive Look for some folks but I can’t get the table to load (with only 3,000 rows and 6 columns).
We generally don’t see performance issues until around 30,000 cells, but queries with fewer cells can still slow down a browser depending on the particulars of your data. You could try a different browser to see if the query loads faster. Feel free to visit help.looker.com with your instance info and the details of what you’d like to visualize in this table, and we can take a look.
any solution here. My queries are return data in less than 2 sec but to get it in a visulization takes long time … we are calculating 100% aggregations on the database and just pulling stuff into looker. One Look takes about 20 seconds to 30 seconds .