I maintain a script that chooses a random server that's known to respond to pings, and performs 100 pings (one second apart). I run this script by hand as a first indicator to determine if I'm having a connectivity or signal quality problem.
The ping command I use is ping -c 100 [server-hostname]
I chose hostnames for my script that were known to respond to ping at the time that I wrote the script, and I tried to keep the list geographically diverse (for example by using university web servers). But this sort of technique requires maintenance, because servers don't consistently allow ping (server configurations change over time), and things like hosted servers disrupt the geographic diversity issue.
I would think that Automator might be a better fit for this sort of task than Instruments, although if you're adept with scripting (shell, python, perl, etc), you could write a script to do it and use much less memory.
As for your situation, the source(s) of failure should dictate what kind of connectivity testing you do. The problem could be due to a piece of hardware within your home/office that needs to be periodically reset, or even replaced. The ping test I describe above doesn't necessarily isolate the source of the problem.
Edit: and to address analysis/graphing, you could perform a ping test at a regular interval (every # minutes), export the packet loss percentage data in a format such as comma-separated values, and use a spreadsheet program to graph the results.
When you added the NAS to the LAN did you move the router? It's possible that even a very minor shift in the position of the router or the antenna could impact the shape of the signal zone.
You might try pairing up with your husband where one of you is in by the router and the other in key use-areas and recording signal strength based on the location, orientation and position of the router and router antennas. (don't know if this model has external antenna, if not rotating the router itself).
There are tools that can give you more detailed report on the signal strength, for instance you might want to download and install Kismac on your MacBook. Kismac and similar tools can also give you some insight into what other networks might be interfering with your own. If you see strong signals on the same channel that you are using you might consider moving your network to another channel.
Best Answer
In my case this was caused by the Juniper/Pulse Secure VPN client's kernel extension, which was active even when not connected to the VPN. Unloading the kernel extension restored speed without a reboot.
Short term fix is to unload the extension, command copied from linked kb article:
Long term solution is to upgrade pulse secure client. I was experiencing this problem with pulse secure 9.0.3(1599). I upgraded to 9.0.3(1667) and the kext is no longer loaded by default. I can connect to the vpn without the kext loaded, and speed is no longer tailing off. Solved!
With pulsesecurefirewall.kext loaded:
Without pulsesecurefirewall.kext loaded:
If your VPN security policy requires "Lock Down Mode" or "Traffic Enforcement", you may need to downgrade instead of upgrade the client.
For future reference, you can view loaded non-apple kexts with:
Edit: What is a kernel extension? A kernel extension is a program that runs within the macOS kernel. Running within the kernel can give performance improvements for certain applications, and also access to APIs that aren't available to normal (user space) programs.
In this case, the pulse client included a kernel extension which provides firewall functionality by inspecting packets as they pass through the kernel. The provided extension is buggy and performance drops over time (maybe it keeps a list of something, and as that list grows, the length of time taken to scan the list increases, so the time to process a packet increases, leading to a drop in throughput??)
Unloading the kext removes the buggy code from the kernel, so that it doesn't affect performance.