You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
38 lines
2.6 KiB
Plaintext
38 lines
2.6 KiB
Plaintext
# Identifying & Diagnosing Bottlenecks
|
|
|
|
When trying to improve performance the most important and value step in the process is identifying and diagnosing bottlenecks. You can attempt to guess at how to write high-performance code from the start, and to a small extent that can help, but with the complexity of the web ecosystem today that is very unlikely to be sufficient. There are just too many layers and components in the system to always get it right. So inevitably you will run in to performance bottlenecks.
|
|
|
|
There are six main steps to solving performance bottlenecks, with some parts done in a cycle:
|
|
|
|
* Describing the performance issue
|
|
* Measuring the issue
|
|
* Identifying the source of the problem
|
|
* Diagnosing the cause
|
|
* Generating possible solutions
|
|
* Selecting and implementing a solution
|
|
* Measuring the issue again
|
|
|
|
## Describing Performance Issues
|
|
|
|
The first step is to identify and qualify the bottleneck. You can start by asking "what are the symptoms?" and "what triggers them?". It's very important to dig in as much as possible at this stage and gather as much information as possible. Here are the questions I generally use to get you started:
|
|
|
|
* What specifically is the issue?
|
|
* A lack of responsiveness?
|
|
* Temporary jankiness?
|
|
* What am I/the user being prevented from doing?
|
|
* When does the issue start?
|
|
* When does it finish?
|
|
* Is the intensity and/or duration variable or constant?
|
|
* Is it predictable? Does it always happen?
|
|
* Does it seem like anything triggers it?
|
|
|
|
You can start with trying to answer these questions or you can come up with your own. The only way to get good at it is practice as it's more and an art than a science at this stage.
|
|
|
|
This stage might not seem that important or the answers might seem obvious but being thorough here can actually save you a lot of time later on. It's very easy to misunderstand a bottleneck and then begin your investigation in the wrong place, wasting valuable time, or even worse, crafting a solution to the wrong problem.
|
|
|
|
## Measuring
|
|
|
|
Once you've described the performance issue in as much detail as you can it's time to move on to the next stage: measuring the issue. This stage is vital to the process. Do not skip this stage. The only way later on to ensure you've actually fixed the problem is to measure the problem to the best of your ability. The better you can quantify the issue the easier the rest of the process will be. This can be very challenging, especially with things that seem immeasurable, like UI jankiness but if you work at it there is generally a way to do. We will discuss a few techniques coming up.
|
|
|
|
|