Performance (mathematical definition) : useful work / used resources.
Performance metrics (practical definitions):
- response time: e.g.
System response time is 2 seconds at 500 concurrent requests, with a CPU load of 50%, and a memory utilization of 92%. - throughput
Time complexity: CPU
Space complexity: Memory
Latency is the delay incurred in communicating a message (the time the message spends “on the wire”). The word latent means inactive or dormant, so the processing of a user action is latent while it is traveling across a network.
Response time is the total time it takes from when a user makes a request until they receive a response.
Performance trade off:
- Memory VS CPU
- Latency VS Throughput
CPU-bound code profiling:
- Sampling profilers: CPU snapshots + imprecise
- Instrumentation profilers: measure start-exit methods + overhead
CPU:
- "self time": total time spent in a method, including the amount of time spent on locks or other blocking behavior
- "self time (cpu)": total time spent in that method, excluding the amount of time the thread was blocked
From here:
- if focus on optimizing the multithreaded interactions, then you should go for "self time" values including the time the threads were blocked
- if not care too much about the multithreaded interactions, then should focus solely on the "self time (cpu)".
Criteria to choose a performance testing tool;
- Scripting: ability to write performance tests "as code".
- Extensible: define / customize measurements, instead of ready-to-use metrics.
- Integration: ability to be used on other tools (CI / CD)
- You should know what model the tool is base on, and selects the tool that fits your need. Ask yourself:
- Do I need just a bunch of quantitative aggregates about cpu/memory?
- Should I focus on a specific topic, and hens, appropriate metrics? e.g. customer experience while browsing;
Tooling;
https://developers.google.com/web/fundamentals/performance/rail
https://www.softwaretestinghelp.com/performance-testing-tools-load-testing-tools/
https://www.guru99.com/performance-testing-tools.html
Databases
If long running request, then debug using explain plans.
Db engine could use different strategies (on runtime) to execute and serve a request.
The chosen strategy depends on tables/column statistics.
If, for some reasons, theses statistics are deeply wrong, then wrong hypotheses will be made by DB engine. In such case, harmful consequences may occur (e.g performance, request running time).
Case study: https://gocardless.com/blog/debugging-the-postgres-query-planner/
Connection pooling
The application uses a database driver to open a connection.
A network socket is opened to connect the application and the database.
The user is authenticated.
The operation completes and the connection may be closed.
The network socket is closed.
Be careful when you define the pool size:
- Too few connections in the pool will result in high latency as each operation waits for a connection to be released.
- Too many connections can also result in high latency as each connection thread is being run in parallel by the system. The time it takes for many threads to complete in parallel is typically higher (because of context switching) than the time it takes a smaller number of threads to run sequentially.
Storage and network performance also will affect the ability of a thread to fully execute. If a thread is blocked by network or storage latency, adding connections to the pool is a good idea so other threads can execute while the original thread is being blocked.
Utilities
OS level
vmstat (virtual memory statistics) is a valuable monitoring utility, which also provides information about block IO and CPU activity in addition to memory.For example, in case of exxecive cpu load, it can help to know CPU dominant : either the user (us cpu) or kernel (sy cpu)
More details
No comments:
Post a Comment