VMware Horizon Community
epa80
Hot Shot
Hot Shot

Epic Hyperspace on Horizon - Slow Performance?

This goes out pretty much exclusively to my fellow members of the Healthcare community.

  • We are currently running Epic Hyperspace May 2020 on our VDI environment, locally installed in the parent image. The Horizon agent installed is 7.10.1 on a 7.10.2 back end. We are fully instant clone.
  • Our endpoints are a mix of ThinOS Wyse 5010 and Wyse 5070 clients, using firmware 8.6_206 and the Dell Horizon 5.1 client. The client is the latest offered by Dell, the OS code is about 3 versions behind. I didn't see anything in the release notes for the later releases that caught my eye for the issue I'll be describing.
  • Our deployment is configured as 3 vCPUs and 6GB of memory per instant clone VM. We reserved all 6GB of memory on the VM parent before deployment.
  • We are deployed on Dell R740XD hosts, with a mix of 8180 and 8280 chipsets.
  • We are 100% vSan all flash on the storage end, dedup and compression is enabled.

Around the same time as we did the most recent upgrade to May 2020, we also migrated the rest of the VDI environment to Windows 10 1809 via Blast (from Windows 7 via PCoIP). Since this has occurred, we have gotten consistent complaints about performance, which we believe is isolated into Hyperspace. The rest of the VM performance apparently is fine. I don't know how confident I feel this is the case, but, it's what we have.

From the Epic side of things inside system pulse (their performance console), we see a definite increase on response time on the pools that are on the 8180s vs. the 8280s. The problem is the workflow could be very different, so, we're having Epic dig in further there to see if they can drill down to a specific workflow causing the hit. I say that because the pools on the 8180 are our clinical Doctor/Nurse kiosks, where as on the 8180 we're offering a generic remote access desktop for remote users. So far, no luck from Epic to isolate a workflow.

Someone can correct me, but, the 8180 processor vs. the 8280 process doesn't SEEM that much better. I mean we're talking a good 7% or 8% higher hit on the 8180s vs. the 8280s on the Epic side. Doesn't sound like much, but, according to Epic, what we see on the better 8280s is still actually higher than they prefer, so, that makes the 8180s look that much worse. And yes they have started to direct us to go in a published app direction, Citrix or RDSH.

While this has been getting looked at from the Epic side, we have done some steps on our side. We recently excluded the actual Epic.exe file from any kind of scans in Deep Security, that we're using for Anti-Malware protection. We've pushed a couple firmware updates out, but, no real reports yet good or bad. We can't go anywhere with the Horizon client on ThinOS, as I said we're at the latest.

The Blast part has me a bit concerned, as that was one of the changes that also went in. Our network is, from a speed/latency perspective, pretty solid I'd say. We've also basically just gone with Blast canned. We aren't doing any GPO/DEM tasks to throttle/optimize Blast really, it's just vanilla out of the box. Should we be looking in that direction?

Apologies for the long rambling post. Hoping someone out there with Epic has felt SOME of this and might have a suggestion or 2.

Thanks in advance.

Reply
0 Kudos
6 Replies
epa80
Hot Shot
Hot Shot

So the focus actually HAS turned further onto the thin clients. As our Wyse 5010s don't support the H.264 codec with Blast, they're using an "adaptive" codec when connected, where as our 5070 clients are indeed able to use the H.264 codec. Again, 5070/5010 we have the same Wyse ThinOS version as well as the same Horizon client, but, hardware limitation is what it is.

I'll continue to update. We're going to look into some DEM tasks regarding Blast to see what we can do. We don't want to switch back to PCoIP.

Reply
0 Kudos
john_f2004
Enthusiast
Enthusiast

We are also on May 2020 and on 7.10.1, still using linked clones and Hyperspace is installed in our parent image as well. We use zero clients and we have a mixture of 2 vCPU - 4 GB, 4 vCPU - 4 GB and 4 vCPU and 8 GB. We use Cisco blades and Pure storage.

We are needing to upgrade/add more hosts as well so that is part of our issue. However there was a slowness in performance once we upgraded to May 2020. It may have been tied to a specific SU we installed as well. But it did increase our exception percentage and Epic was working on a fix for it. We have installed new SU's as well and would need to see if the fix was in place for that, but before that Epic had us edit a registry key named Deepwatch. You may check to see if that is part of the issue in your environment.

We have also discussed looking into using RDSH, but so much can go wrong with how scanners, credit card machines and what not work so we haven't done much with RDSH. We also aren't sure if it is worth the time since within the next year or 2, Hyperdrive will be used which at that point most of the resources are needed on the Hyperspace Web servers at that point.

Reply
0 Kudos
epa80
Hot Shot
Hot Shot

Thanks a lot for this reply. It's funny you mentioned Deepwatch. Our Epic support team did e-mail us about that, but, in the end they said we shouldn't need to use it, so we never put it in. They DID seem kind of wishy washy on it, a bit undecided. You guys saw relief when you applied it?

Going down the Blast optimization path really didn't do much for us. In the end we really don't think that's the issue, so, the search continues. I think we'll apply the key though and see what we get.

Reply
0 Kudos
john_f2004
Enthusiast
Enthusiast

I didn't see any difference, at least in our exception percentage. Our exception percentage was better after we balanced our environment. We had hosts that were running more VMs than they should have.

Our exception percentage definitely went up once we installed May 2020, but has gotten better once we balanced our environment better and possibly the latest SUs we installed. Our exception percentage usually goes up with every upgrade, but never this big of a jump like we saw with May 2020. I would assume your slow performance is just Epic itself and not necessarily your enviornment, unless your vms aren't balanced well like ours was at the time of the upgrade.

Reply
0 Kudos
epa80
Hot Shot
Hot Shot

Gotcha. So you didn't see any exception relief, but, did your users comment one way or the other about performance after the key was put in?

I'm reaching back out to support on our side to see what they think.

Reply
0 Kudos
john_f2004
Enthusiast
Enthusiast

I still had a few of our offices complain about performance even after the registry key was in place. That stopped, atleast I haven't heard of complaints, after we balanced our environment.

 

Yea hopefully Epic comes back with some things to try or maybe an SU that could help with your exception percentages.

Reply
0 Kudos