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

[Dewey_Hunt]

VUMC's production environment is OnBase 18.0.1.39 and Epic 2018 AUG SU. We never see CPU utilization above 10% but also have 16 vCPU XEON E7-4860 v2 CPUs VMWare virtualized Windows Server 2012 R2 with 8 GB RAM and use 8 Servers for a load balanced Production environment with 5,000 concurrent Epic users and 500-600 concurrent OnBase users.

The only issue we have encountered is random slow loading PDF files which is a known issue that Hyland has resolved in 18.0.1.45 - VUMC is upgrading to 18.0.1.52 in the next 30 days.

Our non-Prod (dev/test/training) environment is a single VM also running Windows Server 2012 R2 with 2 vCPUs XEON E7-8837 with 8 GB RAM. We have not document any CPU utilization above 10% running 18.0.1.52.

Both test and prod also run on Flash storage so any temporary file processing/caching is not impacted by a storage bottleneck.

Do you see the same performance issue when testing using the OnBase testing harness?

Are your app pools configured to recycle at a specific time or after a specific number of requests? Are they otherwise configured per the other settings in the MRG?

When running on OnBase 15.0.3.253, we did randomly experience an issue where we would get 99% CPU utilization randomly and configured the App Pools to never exceed 25% CPU. We also implemented nightly app pool recycles, and weekly scheduled IISRESETs and haven't seen that issue since, even after after upgrading to OnBase 18.

[Matthew_Norton]

Thanks for the reply! Just making sure because I didn't see that you mentioned it specifically: is your Epic integration making use of the BinaryDataRetrieval service as well? Our integration runs pretty smoothly except for that piece of it.

I haven't tried testing with the OnBase testing harness, but I'll ask our first line of support about that. Does that have a way to test the BinaryDataRetrieval service?

As far as app pools: they recycle once per day, and they do not recycle after a certain number of requests. They are otherwise configured per the recommendations in the MRG.

Thanks again!

[Jean_Severe]

@Dewey Hunt 

So is each virtualized server running 8GB of RAM?

[Dewey_Hunt]

Correct, each VM is allocated 8 GB of RAM. Our VMs operate normally with 50% to 60% RAM allocated running 3 active App Pool worker processes.