Looker コンテンツのブラウザ負荷は、だいたい(amount of data per cell)×(number of rows)×(number of columns)で見積もれます。大規模なクエリは高速に、また、インスタンスはクエリの結果を迅速に提供する可能性がありますが、ブラウザでは結果の表示に時間がかかる場合や、クラッシュする可能性もあります。この例では、大規模なクエリを開いたユーザーのみが影響を受けます。Looker の他のページは影響を受けません。ブラウザのパフォーマンスを考えて、列数は50以下にすることをお勧めします。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-07-31 UTC。"],[],[],null,["# Performance overview\n\nThis page outlines the basic components that contribute to Looker's performance. This page is intended to outline basic Looker performance concepts so that you can find relevant resources and effectively communicate with Looker Support about your performance issues. This is not a troubleshooting guide, as every performance issue is specific.\n\u003e If you are experiencing performance issues, contact Looker Support. Contact details are located in the last section of this page.\n\nComponent overview\n------------------\n\n\nAt a basic level, Looker is a program running on a server. Looker uses the memory and CPU of that server to run. Every company that uses Looker has their own dedicated server or cluster --- there is no global Looker server. When you log in to Looker from your browser, the browser sends requests to your server for information. The server returns the desired information, and your browser renders it for you.\n\n\nLooker also connects to your database. In this case, the Looker server requests information from the database and the database returns that information to the server.\n\n### Example:\n\n\nWhen you go to your personal folder in Looker to open and interact with a dashboard, this is what happens behind the scenes:\n\n1. You select the link that you expect will open your personal folder page.\n2. Your browser asks your Looker server for information about that folder: \"Are there Looks, dashboards, or other folders in here?\"\n3. Your Looker server returns that information to your browser: \"Yes, there is dashboard A, which contains Looks 1 and 2.\"\n4. Your browser displays the contents of your folder.\n5. You select dashboard A.\n6. Your browser asks the Looker server for info about dashboard A, which includes Look-linked tiles to Looks 1 and 2.\n7. Your Looker server generates the SQL queries needed for Look 1 and 2 and sends them to your database.\n8. Your database returns the result sets for those queries to your Looker server.\n9. Your Looker server sends the data it received from those queries to your browser.\n10. Your browser renders the dashboard using the data it received from your server.\n\nClassifying slowness\n--------------------\n\n\nThere are three major elements described in the preceding example: your database, your Looker server, and your browser. Each contributes to Looker performance and executes a series of processes to deliver your data. The following four elements can impact the efficiency of the database, server, and browser processes:\n\n- Database load\n- Instance load\n- Browser load\n- Network latency\n\n\u003cbr /\u003e\n\n\nThese processes and their potential impact on performance are discussed in the following sections.\n\n### Database load\n\n\nIt takes time for a database to process a SQL query, especially if a query is large or if the database is processing several queries at once. If an Explore, a Look, or a dashboard is taking a long time to return results, the reason could be that the query is slow or that there are several queries running at once. You can check the [**Queries**](/looker/docs/admin-panel-database-queries) page in the **Admin** menu --- or your database console --- to get a better idea of your database's load at any given time.\n\n### Instance load\n\n\nYour Looker server --- commonly referred to as your *Looker instance* --- serves visualizations and pages for everyone who uses the instance. The level of usage at any given time can potentially strain instance resources. If the instance is under a heavy load, a simple non-query processing task --- such as navigating folders --- may take a while to load.\n\n### Browser load\n\n\nFinally, your browser displays the data that Looker serves. The amount of data modern browsers can render is limited. It's possible to crash a browser just by opening an Explore with a large amount of data in it.\n\n\nBrowser load for Looker content can be roughly measured as (`amount of data per cell`) \\* (`number of rows`) \\* (`number of columns`). It is possible for a large query to be fast --- and for your instance to serve the results of the query quickly --- but your browser may take a long time to render the results or may crash. In this example, only users that opened the large query would be impacted. No other pages in Looker would be affected. For browser performance, 50 or fewer columns is recommended.\n\n### Network latency\n\n\nBecause Looker is a web application, every Looker interaction sends and retrieves information through the internet. A poor internet network connection impacts your database, your instance, and your browser. You can confirm that you may be experiencing network latency either by consulting with a colleague who uses Looker on a different network or by asking Looker Support to visit the same page on your instance.\n\nContact Looker Support\n----------------------\n\n\nNow that you have an idea of the basic performance concepts in Looker, you can perform a high-level investigation as to the cause of performance issues on your instance; then reach out to your Looker contact or [Looker Support](https://console.cloud.google.com/support/). When you contact Looker Support, please be as specific as possible and let us know which instance pages are slow and at what times the slowdown occurs."]]