Many customers are exploring and moving towards cloud-based or hosted servers for their WMS and ERP solutions for the benefits or resulting from changes in the application provider.
Before migrating latency-sensitive tasks to external providers, we strongly recommend thorough performance testing. In some cases, we've seen over extensive network hops between customers and their hosted servers.
Fast-moving users, especially those doing rapid scans, may experience delays due to latency. Be sure to include them in testing before going live. Some user training may be required to help prevent application issues or lost input data during delays.
Even slight delays can confuse users, leading to errors from repeated inputs, cancellations, or reboots. This defeats the purpose of scanning devices, which aim to reduce input mistakes.
If cloud performance meets expectations during testing, ensure service agreements guarantee consistent performance — especially on virtualized systems, which may introduce an additional factor with dynamically assigned hardware resources.
Packet Flooding
Some SSH systems and hosted platforms may exhibit packet “flooding,” a condition where screen update packets are generated inefficiently. In certain cases, a single scan, function key, or Enter keypress can trigger up to 150 screen updates—repeatedly clearing and repainting the display.
In contrast, a typical Telnet session would render the next screen only once, possibly in segments but without redundant updates. Packet flooding can degrade performance and cause noticeable screen flickering, as the host system continuously clears and redraws the interface.
The following settings have been implemented within the SmartTE emulation type to address this issue. These items are configured within the Telnet Host Entry (Emulation Settings > Telnet Host Groups). Added as Emulation Properties in the bottom list box:
- Screen Update Delay = Enabled
- Screen Update Delay Max Deferrals = 50
(configurable as 1 – 100) - Screen Update Delay Time = 100
(configurable as 1 – 500) - SSH Session = True
(these settings should not be required in non-SSH sessions) - SSH Keep-Alive Interval = 60000
(this prevents inactivity ending sessions when the host system requires a check-in interval)
These settings offer some configuration ranges for performance tuning. Increasing these numbers may be required for host systems that generate higher numbers of screen updates.
Note that this issue can cause significant increase in the size of the StayLinkedStdOut log file as these packets cannot be delivered and verified by every client instantly from the host system. Using an excludefromlog.txt file to include these lines can help keep the file size under more control:
- Packet Queue is Full
- IOException
Extreme Cases
In extreme cases, additional configuration can be applied to the StayLinked Reliable Protocol.
These settings might further improve the session performance, but they could increase the CPU and/or memory requirements on the server. These settings are not available in the interface. They can be manually added to the espadmin.xml configuration file on the server.
In the protocol node, the queue size and queue throttle are possible entries. They can be added if your file does not have the default entries.
<protocol queue_size="##" queue_throttle="##"/>
The queue size defaults to 32, but can be increased as high as 96. We recommend testing at 64 before adjusting up or down. This increases the server's retention of screen updates for distribution to clients. The higher the number, the more data the server can retain from the host system in the display update buffer, but the more system CPU and memory may be required.
The queue throttle can be set from 1-31, but this value should not be adjusted without consulting the StayLinked Support Team.
Test Environments
Consider ~100 users or less in your test environment. Resource utilization scales in a linear fashion. 1000 sessions should use roughly 10x the resources required by 100 users performing the same tasks and with the same features enabled.
This allows you to enable logging and perform testing and tuning. Once we know the best combination, it can be set on other machines without needing to enable logging.
The following additional links may provide relevant information or details.
Server Migration
Server Tuning Parameters
Share the post "SSH, Cloud, or Hosted Installations"