Starting from scratch. No experience with this product or forum. If there is another path to answer this question, please advise. I apologize in advance if it has been asked and answered. I do not even know where to start to look since documentation is so large.

Overview:
Small office of 8 devices. One server called S. One primary client/user machine called C.
gigabit routers and switches and NICs.
C most often runs as a client of S -- no internet involved. Strictly intranet.
C runs credit card authorization via internet from time to time.
From time to time C has long response time delay. 'Long' means sometimes 10 seconds but can be 90 seconds. No pattern to when delay will hit.
The worst user involved delay is when credit card verification takes 90 seconds.
Most of the time client/sever C/S response is virtually instantaneous.
Lan speedtest usually 300 -600 gbit/sec between C/S. Lan speedtest averages 450 down, 350 up.
During delay lan speedtest goes to 60 to 80 down.
On S, cpu well below 50% and no clear indication that disk util is high and SMART shows no crc/etc errors.
Delays are infrequent and random.
Anti virus etc off.
speedtest.net 45 gbit -50 down, 5 up
C uses internet for credit card auth.

Questions:

  • What type of sensor(s) are needed to identify the cause or source of the delay?
  • Where to go in documentation?
  • Run on S or C or both?
  • Any samples of similar application of PRTG?

Article Comments

Hey Steven,

Thank for your KB-posting.

There are several possibilities for that behavior. The best way would be to monitor the bandwidth of your devices using either SNMP, WMI or flow protocols.

Kindly refer to the following videos and links which should help you in finding the right sensor.

Additionally, I recommend (even if you are new to PRTG) to have a look at our e-learning center.

Kind regards,
Sven


May, 2017 - Permalink

Monitor EVERYTHING on the link between C and S. It is most likeky just a single switch.

Monitor every port on that switch.

My first guess would you issue is network related, more likely a broadcast storm or flooding from somewhere, or something else just using the network, like a VNC session, large emails, or backup images.

Port usage will tell you where the problem is coming from, but also hopefully show you a pattern.


May, 2017 - Permalink