When a store slows down, the first question is whether it is the application or the server. A few Linux commands show CPU, memory, disk, network and the service log. Without that picture you add RAM and keep the same symptom.
These tools ship with ordinary Debian and Ubuntu. iostat is often in the sysstat package. The rest is usually already there.
What to run and why
lscpu shows which CPU actually sits under the VPS. The point is the model and generation, not the vCPU count in the offer. uptime shows load. Read it with the CPU count: a queue on four cores looks different from one on sixteen.
vmstat 1 10 shows every second whether the CPU is waiting on disk, or the hypervisor is taking time from your machine. That second thing, the st column, on a cheap VPS often says more than the CPU chart in the vendor panel. free -h shows memory. Cache is not a lack of RAM. Swap growing under the store at peak is a signal that memory is short or the host is wrong.
iostat -x 1 shows whether the disk is saturated. Then the database and indexing stall even when the CPU “has headroom”. df -hT and df -i show space and file count. A photo catalogue can burn through file count before gigabytes. ss -tulpn shows what listens and on which address. A public database on every interface is visible at once. journalctl and dmesg speak to PHP restarts, out-of-memory and disk errors.
How to collect it for a ticket
On Debian and Ubuntu: apt install sysstat procps iproute2 if something is missing. On a “slow” ticket you save: lscpu, free -h, vmstat 1 10, a dozen lines of iostat -x 1, ss -tulpn, df -hT and today’s PHP log. A Grafana alert calls you earlier. In an incident you still need this dump.
On a VPS the st column in vmstat matters more than the vendor CPU chart. How to read an old CPU: cheap VPS and CPU. Host operations: IT administration.
In short: before you change the pack, measure whether slowness is CPU, disk, memory or neighbours on the host. The vendor panel often does not show that.