After hours of research and troubleshooting we can’t figure it out.
My customer is using Dynamics NAV 2013R2 trough RDP (Terminal Services on Windows server 2008R2). The overall performance on de terminal server is ok, also the RTC response is ok when connected with a full desktop PC trough RDP.
Only the HP Thin Clients have a serious performance issue only with the RTC. A 1-2 delay when opening list pages, scrolling down/up and clicking around. All other programs (Outlook/Word/Internet Explorer etc) working fine, without delays.
We already updated the HP ThinPro firmware and tried al the display options, classic theme, font cleartype etc, but no improvements.
Neither HP or Microsoft is known with this issue, hopefully there is someone with a suitable solution?
by 1-2 you mean seconds? That’s not much taking into consideration the rather weak hardware of these Thin Clients. (except the most costly models)
Besides - how those are connected to the network? If wireless, it might be the bottleneck, as even redrawing screen requires big amounts of data to be transferred.
Check tech spec of your HP model (AND wireless access point, too) for wireless protocols / frequencies supported - only the latest technologies support reasonable speed to avoid any delays. Once more, 1-2 seconds delay is NOT much at all.
Yes, the delay is around the 1-2 seconds, I agree with you that is not much, but as mentioned before, the delay is only in Dynamics NAV RTC, all other applications trough terminal server applications working smoothless.
I suspect it is a graphical render delay combination of HP thin clients, RDP and Dynamics NAV RTC.
All desktops and thinclients are connected with 1GBps LAN.
The users complaining about rendering delays on opening and scrolling trough lookupfields and pages.
Is there a difference in reaction between ThinClient and “normal desktops” ? I suggest the problem might be in another place, and that could explain why only NAV lags.
Well, if you put some 3-5 FlowFields on List Page, then, to make things even funnier, set FILTER on some of these - or even on one of the FF - the scrolling will turn into jump-wait-jump-waitwaitwait-oh-no instead.
The worst case I’ve seen was almost 10 custom-added FFs on ItemList (and corresp. table beneath) - like current Qty per every Location they had and so on. When I asked the Dev team WHY they have gone for it, knowing pretty well that it will be a true performance killer, the answer was - customer insisted on having this data available directly in the List, they do not want to waste time opening Item Availability by Location…
Such design works smoothly only on really monstrous hardware, including both server(s) AND workstations, because much of filtering is done on workstation, NOT server. Only the latest 3-tier NAV versions start to make use of (some of) MSSQL capabilities, earlier it was SELECT * FROM eventually even without WHERE, when only a couple of fields (of maybe 100+ existing in the table) and a small subset of records were needed.
There are indeed flow fields added on page lists, exactly for the reason you mentioned
Because Terminal Server is used as RTC, witch is a HP Performance Server, and performed well trough full Windows desktops PC’s, I didn’t thought that could be the reason of the delays/jumps etc.
Next week we have an appointment at the customer location, we further investigate the pages. I’ll let you know when it is resolved.
