Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Eine der besten Möglichkeiten, Nutzern die Analyse von Daten zu erleichtern, besteht darin, ihnen ausgewählte Datenansichten zur Verfügung zu stellen. Dazu können Sie effektive Looker-Dashboards erstellen. Wenn Sie die Leistung Ihrer Dashboards optimieren möchten, sollten Sie die Tipps auf dieser Seite berücksichtigen.
Looker-Dashboards werden im Browser geladen. Beachten Sie die folgenden Hinweise, um eine optimale Leistung zu erzielen.
Das wichtigste Element der Dashboard-Leistung ist die Leistung der zugrunde liegenden SQL-Abfrage. Wenn ein Dashboard-Element nicht aus dem Cache zurückgegeben wird, wird eine SQL-Abfrage ausgeführt, die in der zugrunde liegenden Datenbank einige Zeit in Anspruch nimmt. Weitere Informationen zum Erstellen leistungsfähiger Abfragen finden Sie auf der Seite mit Best Practices zur Optimierung der Looker-Leistung im Abschnitt Abfrageleistung optimieren.
Einige Komponenten sind speicherintensiver als SQL-bezogen. Dies kann zu einer langsamen Leistung in Dashboards führen:
Das Datenvolumen hat den größten Einfluss auf die Leistung. Je mehr Daten in einem einzelnen Element zurückgegeben werden, desto mehr Arbeitsspeicher wird verbraucht. Layouts und Dashboard-Elemente, die mit vielen Tausenden von Datenpunkten zurückgegeben werden, verbrauchen mehr Arbeitsspeicher.
Begrenzen Sie die Anzahl der Dashboard-Elemente. Es gibt keine feste Regel für die Anzahl, da sich das Design eines einzelnen Elements aufgrund einiger Faktoren auf den Speicherverbrauch auswirkt (siehe weiter unten auf dieser Seite). Vermeiden Sie jedoch Dashboards mit 25 oder mehr Abfragen. Sie können die Leistung des Dashboards optimieren, indem Sie Navigationslinks zwischen Dashboards erstellen oder Links zu benutzerdefinierten URLs erstellen, um eine ausgewählte Navigation von Dashboard zu Dashboard zu erstellen. Sie können auch ähnliche Messwerte in derselben Visualisierung mit einem einzelnen Wert zusammenführen, um viele Visualisierungen mit einzelnen Kacheln zu vermeiden.
Dashboard-Einstellungen strategisch verwenden Wenn für Ihr Dashboard die automatische Aktualisierung verwendet wird, darf diese nicht schneller erfolgen als Ihr ETL-Prozess. Im Allgemeinen sollten Sie die automatische Aktualisierung nicht kürzer als 15 Minuten einstellen. Verwenden Sie Beim Laden ausführen nicht, wenn das Dashboard gefiltert werden soll. Mit erforderlichen Filtern können Sie verhindern, dass Nutzer Dashboards ohne die erforderlichen Filter ausführen.
Caching nutzen Es empfiehlt sich, Datengruppen zu verwenden, um alle Looker-Inhalte (Dashboards, Looks, Zeitpläne) mit Ihrem ETL-Prozess zu synchronisieren. So lassen sich unnötige Abfragen vermeiden, wenn die Daten nicht auf dem neuesten Stand sind.
Funktionen zur Verarbeitung nach der Abfrage, z. B. zusammengeführte Ergebnisse, benutzerdefinierte Felder und Tabellenkalkulationen, belegen Arbeitsspeicher. Je mehr Funktionen für die Verarbeitung nach der Abfrage verwendet werden, desto mehr Arbeitsspeicher wird belegt. Wenn Sie dieselben Tabellenkalkulationen, zusammengeführten Ergebnisse oder benutzerdefinierten Felder in mehreren Looks und Dashboards verwenden, sollten Sie sie nach Möglichkeit in Ihr LookML-Modell einfügen. Fügen Sie einem Dashboard im Allgemeinen nicht mehr als vier Kacheln mit zusammengeführten Ergebnissen hinzu.
Pivotierte Dimensionen belegen Arbeitsspeicher. Je mehr Dimensionen in einem Look oder einer Dashboard-Kachel pivotiert werden, desto mehr Arbeitsspeicher wird beim Laden des Dashboards benötigt. Wie im ersten Aufzählungspunkt erwähnt, liegt das daran, dass mehr Daten verwendet werden, da mehr Daten zurückgegeben werden. Wenn die Dimension, für die Sie eine Pivot-Analyse erstellen, eine hohe Kardinalität (viele eindeutige Werte) hat, gibt es für jeden Wert eine Spalte. Filtern Sie auf Dashboard- oder Look-Ebene, damit Nutzer die Dimensionswerte auswählen können, die sie am liebsten vergleichen möchten, anstatt alles gleichzeitig anzuzeigen.
Viele Spalten und Zeilen verbrauchen mehr Arbeitsspeicher. Für eine optimale Browser-Leistung werden maximal 50 Spalten empfohlen. Wie bereits im ersten Aufzählungspunkt erwähnt, können Suchanfragen, die viele Zeilen und Spalten zurückgeben, die Leistung beeinträchtigen. Filtern Sie auf Dashboard- oder Look-Ebene, um die Anzahl der Ergebnisse in einem Element zu reduzieren.
Verwenden Sie gemeinsame Filter mit einer einzelnen Abfrage, um ein einzelnes Abfrageergebnis auf mehreren Kacheln zu rendern. Dadurch sollte die Gesamtzahl der Abfragen, die über das Dashboard ausgeführt werden, reduziert werden, da mehrere Dashboard-Elemente mit einer einzigen Abfrage ausgeliefert werden.
Verwenden Sie die Option Alle Ergebnisse sparsam, um Abfragen auszuführen, da einige Abfragen sehr groß sein können und den Looker-Server bei der Verarbeitung überlasten.
Testen Sie die Dashboard-Leistung, nachdem Sie Elemente hinzugefügt haben. Rufen Sie während der Erstellung immer wieder das Dashboard auf und aktualisieren Sie die Seite, um zu sehen, wie sich die Leistung durch das Hinzufügen weiterer Looks verändert.
Wenn Sie mit Ihrem neuen Looker-Dashboard zufrieden sind, sollten Sie Ordnerberechtigungen verwenden, damit das Dashboard nicht versehentlich geändert werden kann. Mit Nutzergruppen können Sie den Zugriff auf Inhalte und Berechtigungen im Bulk-Verfahren statt auf Nutzerebene verwalten.
Wenn Sie Leistungsprobleme haben, wenden Sie sich direkt an den Looker-Support. Unser Team hilft Ihnen gerne weiter.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-07-31 (UTC)."],[],[],null,["# Considerations when building performant Looker dashboards\n\nOne of the best ways to empower users to explore data is by providing them with curated views by [building effective Looker dashboards](/looker/docs/creating-user-defined-dashboards). If you want to create a great performance experience for your users, consider the tips on this page as you design your dashboards.\n\n\nLooker dashboards load in the browser. To build for optimal performance, keep the following facts in mind.\n\n\nThe most important element of dashboard performance is the underlying SQL query performance. Each dashboard element, when not returned from cache, runs a SQL query that takes time to execute on the underlying database. See the **Optimize Query Performance** section of the [Optimize Looker performance](/looker/docs/best-practices/how-to-optimize-looker-server-performance#optimize-query-performance) Best Practices page for more details regarding building performant queries.\n\n\u003cbr /\u003e\n\n\nSome components are more memory-intensive than they are SQL-related --- these can cause slow performance in dashboards:\n\n-\n **Data volume has the greatest impact on performance.** The more data that is returned\n in an individual element, the more memory resources will be consumed. Looks and dashboard elements that are returned with many thousands of data points will use more memory.\n\n-\n **Limit the number of dashboard elements.** There\n is no hard and fast rule about the number, since the design of a single\n element impacts its memory consumption based on a few factors (covered\n later on this page). However, avoid creating dashboards with 25 or more queries. Keep dashboard performance slick by creating navigation links\n between dashboards or by [creating links to custom URLs](/looker/docs/reference/param-field-link) to\n create a curated navigation from dashboard to dashboard. You can also\n try concatenating similar measures into the same single value visualization to\n avoid many single tile visualizations.\n\n-\n **Use dashboard settings strategically.** If\n your dashboard uses [autorefresh](/looker/docs/editing-user-defined-dashboards#autorefresh), make sure it refreshes no faster than your ETL process. In general, you should avoid setting the autorefresh faster than 15 minutes. Don't use [run on load](/looker/docs/editing-user-defined-dashboards#run_on_load) if the dashboard is meant to be filtered. Use [required filters](/looker/docs/filters-user-defined-dashboards#requiring_a_filter_value) to prevent users from running dashboards without the\n necessary filters.\n\n-\n **Leverage caching.** It's best practice to use [datagroups](/looker/docs/caching-and-datagroups) to sync all Looker content (dashboards, Looks, schedules) with your ETL process. This helps\n avoid unnecessary querying when the data is not up to date.\n\n-\n **Post-query processing features, such as [merged results](/looker/docs/merged-results), [custom fields](/looker/docs/custom-fields), and [table calculations](/looker/docs/table-calculations), consume memory.** The\n more post-query processing features used, the more memory is consumed. If you are using the same\n table calculations, merged results, or custom fields across multiple Looks\n and dashboards, consider hard-coding them into your LookML model wherever possible. In general, don't add more than four merged results tiles to a dashboard.\n\n-\n **Pivoted dimensions consume memory.** The\n more dimensions that are [pivoted](/looker/docs/creating-and-editing-explores#pivoting_dimensions) in a Look or dashboard tile, the more memory is consumed when the dashboard\n is loaded. As mentioned in the first bullet point, this is because more data is used as more data is returned. If the dimension you are pivoting has high cardinality (many unique values), there will be a column for each value. Filter at the dashboard or Look level to allow the user to select the dimension values that they are most interested in comparing, as opposed to showing everything at once.\n\n-\n **Having many columns and rows consumes more memory.** For browser performance, 50 or fewer columns is recommended. Again, as discussed in the first bullet point, Looks returning a high volume of rows and many columns can slow performance. Filter at the dashboard or Look level to reduce the number of results within an element.\n\n-\n Leverage [shared filters with a single query](https://community.looker.com/technical-tips-tricks-1021/shared-filters-on-single-value-charts-performance-technique-29987) to\n render a single query result across multiple tiles. This should reduce\n the total number of queries run from the dashboard by leveraging one\n query to power multiple dashboard elements.\n\n-\n **[deliver queries](/looker/docs/and-or-filters-in-explores\u003eAND/OR filters\u003c/a\u003e\u003c/strong\u003e. There is no limit to the number of groups that can be created; however, excessive filter groups may impact browser performance.\n \u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003e\n Download or \u003ca href=) using the [**All Results**](/looker/docs/downloading#all_results) option sparingly, as some queries can be very large and overwhelm the Looker server when processed.**\n\n**Make sure that you test dashboard performance after you add elements. As you are building, continue to navigate to the dashboard and refresh the page to determine how performance is impacted as you add additional Looks.\nOnce you are satisfied with your new Looker dashboard, be sure to utilize [folder permissioning](/looker/docs/organizing-spaces#folder_access_levels) to\nensure that the dashboard cannot inadvertently be changed. Leverage [user groups](/looker/docs/admin-panel-users-groups) to manage content access and permissions in bulk, instead of on an individual-user basis.\nIf you're having performance issues, reach out to [Looker Support](https://console.cloud.google.com/support/) directly --- our team is always ready to investigate and lend a hand!**"]]
