Minor fixes to performance troubleshooting guide (#17221)

* Minor fixes to performance troubleshooting guide

* Update docs/troubleshooting-guide/performance.md

Co-authored-by: flamber <1447303+flamber@users.noreply.github.com>

* Fixing a few small issues with the performance troubleshooting guide.

* Another fix to performance troubleshooting

Co-authored-by: flamber <1447303+flamber@users.noreply.github.com>

docs/troubleshooting-guide/performance.md

-## Performance
+# My question or dashboard is slow
 
 In order to troubleshoot performance problems, you first need to understand what happens when a question or dashboard is created or updated in Metabase. Before diving into specifics, you may want to read our article on [Metabase at scale][metabase-at-scale].
 
@@ -24,7 +24,7 @@ In order to troubleshoot performance problems, you first need to understand what
 
 Each of the steps described is a potential performance bottleneck.
 
-### The Metabase instance is getting so much traffic that loading the HTML page is slow.
+### The Metabase instance is getting so much traffic that loading the HTML page is slow
 
 This is extremely rare, since our front end is not very large and browsers cache our JavaScript, but it's easy to rule out. What is more common is the lack of HTTP/2 or the lack of available connections to the application database; we cover both topics in our article on [Metabase at scale][metabase-at-scale].
 
@@ -36,25 +36,19 @@ This is extremely rare, since our front end is not very large and browsers cache
 2.  Check the server logs for Metabase's application database.
 3.  Look at page load times in the browser console. If it's taking a long time to load our HTML, CSS, or JavaScript, check to see whether a proxy, firewall, or other network component is slowing things down.
 
-### Caching is disabled.
+### The answer you want isn't cached
 
-By default caching is disabled so that we always re-run every question. However, if your data is only being updated every few seconds or minutes, you will improve performance by enabling caching. Note that ad hoc queries and exports are *not* cached, so doing a lot of either can impact performance.
+By default caching is disabled so that we always re-run every question. However, if your data is only being updated every few seconds or minutes, you will improve performance by enabling caching. Note that:
 
-**How to detect this:** Open the Admin Panel, go to "Settings", and look in the "Caching" tab to see whether caching is enabled or not.
-
-**How to fix this:** [This guide][admin-caching] explains how to change the minimum query duration (we cache anything that takes longer than that to run) and the maximum cache size for each query result. You may need to experiment with these values over several days to find the best balance.
-
-### The answer you want isn't cached.
+1. Ad hoc queries and exports are *not* cached, so doing a lot of either can impact performance.
+2. Since cached values are stored in the application database they will still be there if Metabase restarts.
+3. Each question (and any filter combination) is its own query, so if different users are viewing the same question with different filters, each will have to load once before it's cached. This is particularly obvious with [data sandboxing][data-sandboxing]: filtering the data based on the user's identity means that each user's question is slightly different.
 
-Each question (and any filter combination) is its own query, so if different users are viewing the same question with different filters, each will have to load once before it's cached. This is particularly obvious with [data sandboxing][data-sandboxing]: filtering the data based on the user's identity means that each user's question is slightly different.
-
-Additionally, since cached values are stored in the application database they will still be there if Metabase restarts, but only if the cache duration is still valid. 
-
-**How to detect this:** If you are sure that caching is enabled (discussed above), then look at Metabase's logs or in the server's logs to see when it was last restarted. If performance problems are caused by data sandboxing, you may want to consider enlarging the cache.
+**How to detect this:** Open the Admin Panel, go to "Settings", and look in the "Caching" tab to see whether caching is enabled or not.
 
-**How to fix this:** 
+**How to fix this:** [This guide][admin-caching] explains how to change the minimum query duration (we cache anything that takes longer than that to run) and the maximum cache size for each query result. You may need to experiment with these values over several days to find the best balance. If the problem appears to be caused by a high proportion of sandboxed queries, check that the cache is large enough to store all of their results.
 
-### The database is overloaded by other traffic.
+### The database is overloaded by other traffic
 
 Metabase is usually not the only application using your database, and you may not be the only person using Metabase. If someone else has opened a dashboard that launches a couple of dozen long-running queries, everyone else may then have to wait until database connections become free. Our article on [Metabase at scale][metabase-at-scale] discusses this in more detail, and our article on [making dashboards faster][faster-dashboards] may help as well.
 
@@ -64,7 +58,7 @@ Metabase is usually not the only application using your database, and you may no
 
 Note: you may also see your database being overloaded if you're using the same database as Metabase's app database and for your own data. We strongly recommend that you don't do this in a production system or if you have more than a handful of users.
 
-### The question itself is slow.
+### The question itself is slow
 
 Joining half a dozen tables, each with a few million rows, simply takes a lot of time. On the other hand, while we do our best to create fully-formed SQL queries from graphical questions, SQL snippets, and questions that use other questions as starting points, it's a hard problem---particularly across as many databases as we support. We also don't take advantage of every quirk of every backend database. For example, Redshift stores values in columns rather than rows: some queries that work well for row-oriented databases are slow on columns and vice versa.
 
@@ -82,7 +76,7 @@ Joining half a dozen tables, each with a few million rows, simply takes a lot of
 2. You can use your SQL in place of the code we generate, and [make its result available][organizing-sql] to people who prefer the Notebook Editor as a starting point for their questions.
 3. And please file a bug report to help us figure out how to generate better SQL.
 
-### Values are repeatedly being converted on the fly.
+### Values are repeatedly being converted on the fly
 
 Low performance when using Metabase can also be caused by incorrect typing of columns, e.g., by storing a numeric value as a string.  When this happens, the query converts values on the fly each time the query is run.
 
@@ -90,13 +84,13 @@ Low performance when using Metabase can also be caused by incorrect typing of co
 
 **How to fix this:** Amend the database schema to store numbers as numbers, timestamps as timestamps, and so on, rather than as strings or other data types.
 
-### Metabase is running on an under-powered machine.
+### Metabase is running on an under-powered machine
 
 **How to detect this:** Checking the performance logs for the server where Metabase is running will tell you whether it is hitting CPU or memory limits. However, it's much more likely that the database itself is hitting its limits, so please check it first.
 
 **How to fix this:** Upgrade to a more powerful server or one with more memory. If you would like this taken care of you, along with backups, cache configuration, and so on, please consider using [Metabase Cloud][metabase-start].
 
-### A dashboard contains too many questions.
+### A dashboard contains too many questions
 
 When Metabase displays a dashboard, it re-runs all of the questions. We do our best to do this concurrently, and the network layers and the database itself also do what they can, but a dashboard with a hundred cards is going to be slower than a single question. And if your dashboard contains filters, then each time someone changes a filter setting, all of the cards that depend on it have to re-execute. Careful dashboard design can prevent or eliminate these problems.