Server performance with BinaryDataRetrieval.svc

[Matthew_Norton]

Hi all,

Has anyone had any experience using the app server's Epic "BinaryDataRetrieval" service (AppServer/Services/Epic/BinaryDataRetrieval.svc)? Our Epic TEST environment recently started using this service to display thumbnail images of OnBase documents that are being viewed from within Epic Hyperspace, and it seems to be extremely taxing on the app server's CPU.

For example, I can be the only user in our Epic TEST environment viewing thumbnails, but if I try to load them quickly (as a user might if they are scrolling down through the list of documents on a chart), I can single-handedly cause the CPU on the app server to reach 95-100% utilization. RAM utilization does not seem to increase significantly.

The issue does seem to be at least somewhat related to the file types that are being displayed. If I'm just viewing documents composed of image files, the CPU utilization reaches 50-75%. If I add in eforms, that's when it reaches 95-100%.

We're already working with our first line of support on this, but I figured someone else out there must be using this in their PROD environment, so just curious if anyone else has run into this.  And, if so, what kind of server setup/specs do you have on the machine(s) that host the BinaryDataRetrieval service?

For what it's worth, we did have this running in our PROD environment for about a day, but it either stopped or severely slowed down the other pieces of our Epic integration, so we had to turn it off.

Other info:

OnBase version: 18.0.1.39
Epic Hyperspace version: February 2019
Server specs: Windows Server 2016, 2 CPUs running at 2.3 GHz (they "boost" up to 3.5 GHz when needed), 8 GB of memory

Thanks,
Matt

[Jean_Severe]

@Dewey Hunt 

And each VM is allocated 2 of those E7-4860 processors?

I'm asking these questions because we're currently overhauling our OnBase infrastructure, and want to get an idea of what hardware other people are running (we've had dozens of incidents reporting slowdowns just this week).

[Dewey_Hunt]

The benefits of using VM infrastructure is we can easily upgrade the base hardware. Today our systems running XEON Platinum 8168 physical CPUs and we allocate 8 or 16 vCPUs per VM. ESX hosts allow the RAM and CPUs to be over allocated and dynamically used as the individual VM's demand increase or decrease. To your comment about slowness, there are many variables that impact performance, RAM and CPU certainly are factors, but your database and image storage latency along with network bandwidth can have a much bigger impact that the App Server VM performance. We experienced performance issues at busy remote office that was caused by network latency issues rather than available bandwidth or our App Server performance.

[Jean_Severe]

@Dewey Hunt 

Thanks a million.

Who did you all consult to help with building out all of this OnBase architecture? Did you have to contact Hyland Professional Services at all for assistance?

[Dewey_Hunt]

VUMC a very large organization and has an entire group devoted to managing our infrastructure. That group sized everything based on the specifications from Hyland as well as our growth and experience over the 15 years of being an OnBase site. We did engage Hyland's professional services when we integrated with Enterprise Epic but it was more of a consulting role to deal with issues and to have the benefit of their best practices experience with Epic. I would strongly suggest having experienced OnBase administrators employed at your facility.