HandiSoft - Slow performance in HandiSoft applications

Slow performance may be indicative of an issue with the switching infrastructure on your network. This may manifest itself when the HandiSoft programs interact with each other, and is usually evident when the applications perform well on the server that they are hosted, but not over the network client machines. We recommend that you try the same HandiSoft functions on the server and make a comparison.
​
Before looking into the network switches for the cause of the slowdown, it is important to first verify that the slow performance is not due to:

Refer to the article Hardware and Software Recommendations or alternatively, forward this article to your IT Consultant for additional assistance. If there is evidence that the slow performance cause lies in switching infrastructure, the next step in troubleshooting is to identify one or more network paths that are experiencing frequent occasions of slow performance. Identify particular workstations and particular servers between which communication is frequently slow, and map out the network path between them - i.e. which ports of which switches do the packets exchanged between the workstation and server pass-through. Work along the identified network path(s) looking for evidence of congestion, corruption, or collisions.
​

Look for ports that are oversubscribed. An oversubscribed port is one from which the switch is attempting to deliver data at a rate higher than the port's bandwidth can allow. When this occurs, some packets must end up being dropped, potentially resulting in a "cannot read". The users whose packets are being dropped will experience a slowdown in their file transfers or in the responsiveness of the network-based applications they are running.
​
An important step in diagnosing network slowdowns is to look for oversubscribed ports in the network. One way to find oversubscribed ports is to use a tool that will report the utilisation of network ports. A variety of such tools exist, most network management packages provide facilities for monitoring port utilisation. The popular traffic graphing tool MRTG is widely used for the task of port utilisation monitoring and graphing. Other commercial tools, similar to MRTG, e.g. PRTG, provide similar port utilisation monitoring and graphing capabilities.

If packets are being corrupted by faulty cabling, or by electrical interference, or by switch hardware faults, then the corrupted packets will be dropped by the receiving switch. A high rate of corrupt packets will cause a slowdown in network performance, as the hosts sending the dropped packets will have to resend them. You will / may receive a message indicating the data is corrupted and you will need to rebuild.

One special case to consider is when a port is reporting a high rate of collisions. On full duplex Ports, there should never be any collisions, as sent and received packets are exchanged in different channels and cannot collide with each other. If a port is reporting a high rate of collisions, it is highly likely that the port is in half-duplex mode, and the port on the switch at the other end of the link is in full-duplex mode.
​
As a result, the switch in full-duplex mode will send data even while the half-duplex port is transmitting (which is normal behaviour for a full-duplex port). The half-duplex port, though, will see this situation as causing collisions and will frequently abort packet sending and retry.
​
This can significantly reduce throughput. This duplex mismatch commonly occurs if one end of the link has a fixed speed/duplex, and the port at the other end is auto-negotiating. The auto-negotiating port will not be able to detect the duplex state of the peer port, and will default to half duplex.
​
The solution to the duplex mismatch problem is to change the configuration of the ports to ensure that they will come up with the same duplex state at both ends.
​
​Ping can be a useful tool in monitoring for network slowdown
Ping is a simple, effective way to monitor the round-trip time along particular network paths.
​
By pinging between various pairs of points in the network, it is often possible to identify the point(s) in the network at which packets are being queued or dropped.
​
It is important to have a clear understanding of the best way to make use of ping.
​
Simply looking at the average round-trip time of the pings between one device and another does not necessarily provide very useful information about network performance. Typically, the bulk of the round-trip time of a ping is not due to switch forwarding latency. Rather, the bulk of the time is due to the software processing of the ping packet in the sending and receiving devices. Different networking devices process ping packets differently. Some will treat ping packets as high priority and respond to them very quickly; others will not give such high priority to ping, which will result in a longer round-trip time.
​
Consistently high round-trip time for pings to an Ethernet switch does not provide any evidence that the switch is experiencing congestion, or even that its CPU is heavily loaded; it just indicates that this switch does not have a fast turnaround of ping packets.
​
When using ping to help investigate network slowdowns, it is far more important to look for significant:

A significant variation of ping round-trip times, or intermittent loss of ping responses, could indicate network congestion.
​
Packets sitting in egress queues when ports are oversubscribed can cause variations in ping round-trip times. Similarly, when oversubscribed ports have to drop packets, that can cause intermittent loss of ping responses.
​
However, be aware that significant variations of ping round-trip times or intermittent loss of ping responses are not highly reliable indicators of network congestion. These variations could just as easily be caused by variable CPU loading of the target device.
​
While ping is useful as a simple way to monitor whether there is variation in the loading on the network or the network's hosts, it is too simple to be a useful diagnostic tool.
​
Once you have reason to believe that there are overloaded or slow-performing paths in your network, then further investigation is needed to gather more precise information than can be gained from ping.
​
​Resign Users from HandiSoft Programs
Slowness may occur when opening your HandiSoft programs if your startup menu Users list is large compared to the number of staff members using the programs.
​