# Vision client running slowly on remote client machines

**URL:** <https://forum.inductiveautomation.com/t/vision-client-running-slowly-on-remote-client-machines/67264>\
**Category:** Ignition\
**Tags:** ignition80, vision\
**Created:** [December 6, 2022, 6:09am UTC](https://forum.inductiveautomation.com/t/vision-client-running-slowly-on-remote-client-machines/67264 "2022-12-06T06:09:30Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Hvk05921](https://avatars.discourse-cdn.com/v4/letter/h/9f8e36/32.png) [@Hvk05921](https://forum.inductiveautomation.com/u/Hvk05921)\
**Post date:** [December 6, 2022, 6:09am UTC](https://forum.inductiveautomation.com/t/vision-client-running-slowly-on-remote-client-machines/67264/1 "2022-12-06T06:09:30Z")

</div>

Hi,

We have Ignition gateway installed on one server machine and running multiple clients on remote machines. we observed our vision client is taking too much time to open window, popup and slow performance.  
as we observed the Zulu platform is taking memory usage about 4 GB.  
we have increased initial and maximum memory to 1024 MB & 4096 MB respectively.  
still we are facing slowdown issue for client machines.  
client machine RAM is 8 GB out of which overall all 7.1 GB is being used  
we are not sure what should be done next, Please help !  
 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/c/a/cacbf17c7a3f9eb4f378a25f2e56ce935723ea9d.png)

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [December 6, 2022, 1:09pm UTC](https://forum.inductiveautomation.com/t/vision-client-running-slowly-on-remote-client-machines/67264/2 "2022-12-06T13:09:56Z")

</div>

This is almost always caused by poor programming habits, where `system.*` calls that need to talk to the Ignition gateway are included in user interface event scripts (which run on the single User Interface thread). This stalls (freezes) the user interface. `system.tag.*`, `system.opc.*`, `system.net.*`, and `system.db.*` operations are the most likely to be at fault. This is often not noticed on a LAN, where response times to the gateway are ~1ms or so. When response times are tens or hundreds of milliseconds, BOOM.

Such network-dependent script functions should be limited to background threads, or their use eliminated by using tag bindings and query bindings instead. (Those run in the background automatically.)