Find and fix a slow page

Find and fix a slow page

A user says a page is slow. This guide goes from that sentence to the line you change, and then checks that the change helped. It uses the pages you already have: the bar, Reports, Hot spots and Queries. Hot spots is a BoxLang+ page. The first steps work on Free.

1. Find out which page, and how slow

Open Reports and read the Slowest list for the last 24 hours or 7 days. It orders URLs by p95, the time that 95 of 100 requests stay under, so one unlucky request does not put a URL on top. Press the URL. Its page shows the hits, the average and the p95 over time, and where its time goes: the database, templates, outgoing HTTP and the rest.

Write down the p95 now. It is the number to beat.

This tells you the kind of problem before you look at any code:

2. Look at where the time went

Switch Hot spots on once (Settings, Collection). Every request over one second is looked at from then on, and the pictures of a URL grow with each slow run.

Open the URL in Reports and read the Hot spots card. The widest bar is where to start. Read it from the top: a function that holds 70 percent of the time and calls nothing wide has the problem in itself. Under it, Where the time went lists the places that spent the time, widest first.

If the page is not slow often enough to wait for, open In flight while it runs and press Hot spots on the request. If you know the URL and want a picture right away, press Watch this URL for 10 min and load the page yourself a few times.

How to read what you see:

• One wide bar in your code with nothing under it. A loop or a calculation. Look at the line shown under the name.
• A wide bar of waiting on the database. The statement is in the label. Copy it to your database tool with EXPLAIN, or find it in Queries.
• Many narrow bars of the same statement. The same query runs again and again, the N+1 pattern. Query once and join, or cache the result. The request page counts the queries.
• Sleeping or waiting for another thread. The request is waiting, not working. Look for a lock (lock, synchronized), a sleep or a pool that is too small.
• A wide grey bar (press All frames). The server or BoxLang does the work. Often it is compilation on the first run of a page, which goes away on the second.

3. Check the statements

Open Queries and sort by Longest in total. A statement that ran 2000 times at 5 ms is 10 seconds in a day, more than one that ran once at 500 ms. The N+1 and slow query checks on the request page point at the same thing.

4. Change one thing

Change the one place the picture points at, and only that, so you know what helped. Typical changes:

• Move a query out of a loop, or add an index the statement can use.
• Cache a result that does not change for each request.
• Call a slow service once, not once for each row, or in the background.
• Break up a lock that holds work that needs no lock.

5. Prove it

Load the page again after the deploy and open the same URL in Reports with a range that starts after the deploy. The p95 should be lower, and the Hot spots picture should have a different widest bar, or a smaller one. If the number did not move, the picture shows what is still wide. Do not stop at "it feels faster": the picture and the p95 are the proof, and the next widest bar is the next thing to look at.

Leave Hot spots on if you can spare a little CPU. It only looks at slow requests, pauses by itself above 85 percent CPU and ends a look after 60 seconds. To keep it from running for ever, set collectors.hotspots.offAfterMinutes.

Ask Lensy

If the assistant is on, ask it "why is /reports/monthly slow?". It reads the merged Hot spots of that URL and the statements, and answers in words with the place to look at. See Ask Lens and AI.

See also

• Hot spots
• Performance under load, the cost of BxLens itself
• The bar: Timeline and Queries, the same questions for one request on your own page