WebViewer Server Performance

This document is meant to demonstrate what kind of performance you should expect out of WebViewer Server in various situations. You may use the information here as a starting point in evaluating your particular deployment of WebViewer Server.

Some things mentioned have a particular meaning, this section will detail that.

• Run Time : Time it took the system to actually execute a task
• Queue Time : The time that a task was waiting to be executed
• Request Duration : The time it took for a single user to perform their request tasks.
• Bottleneck : An aspect of the system used for testing that is responsible for slowing performance down.

• These tests are accurate in a real world situation where your users are never reusing their documents. That means that your performance may improve based on how often cached documents are used in your environment.
• Depending on the browsers and devices your clients use there will be some variation in the work that WebViewer, and WebViewer Server, each do. The better (more modern) your users devices are, the less work WebViewer Server has to do.

In this section we will detail what one should actually expect based on our testing scenario.

• Instance type for the tests is a c5d.4xLarge instance from Amazon Web Services
  • https://aws.amazon.com/ec2/instance-types/c5/
• Custom 2nd generation Intel Xeon Scalable Processors (Cascade Lake) with a sustained all core Turbo frequency of 3.6GHz and single core turbo frequency of up to 3.9GHz or 1st generation Intel Xeon Platinum 8000 series (Skylake-SP) processor with a sustained all core Turbo frequency of up to 3.4GHz, and single core turbo frequency of up to 3.5 GHz.
  • Contains 16 cores
• Uses a NVMe SSD which offers a bandwidth of 4750 MB/s and 400 GB of space
• Performs with network speeds up to 10 GB/s
  • In practice, our system caps around 8 GB/s
• This server recieves requests directly from each user
• The files this server processes are available on the same private network via an AWS S3 bucket
• Each user 'session' represents what would typically happen during a document initial load on WebViewer connected to WebViewer Server
• The only Webviewer Server option used here is TRN_MAX_CACHED_MB which is set to 50000 MB

All test scenarios are done via various test loads using the same test environment. For each user calling the server, we request an initial load that you would typically execute if using WebViewer with WebViewer Server as a single user.

This test will show how well WebViewer Server can handle easier documents that meet the following criteria:

• Lower than 1 MB in size
• Minimal amount of pages
• Pages with simple drawing operations

The documents used were the following:

• 3 page drug brochure, 1 MB
• 5 page how to guide, 196 KB
• 82 page reference doc, 753 KB
• 2 page project doc, 75 KB
• 4 page resume, 482 KB

During this test we executed 89012 individual request sessions over 4 hours. The averages are as follows:

We saw memory usage, CPU usage and disk/network usage steadily climb along the same slope. We would expect this rise to continue going on as users were steadily increased. None of these aspects of the server are a bottleneck in this case and increasing any of the 4 would improve performance. One could likely push the load to 20 sessions/second with this environment.

Disk usage reached our defined limit (TRN_MAX_CACHED_MB) and hovered at this point.

This test will show how well WebViewer Server can handle a typical stress load with documents that meet the following criteria:

• Lower than 100 MB in size
• Moderate amount of pages
• Moderate complexity drawing operations

The documents used were the following:

• 8 page org chart utilizing images, 979 KB
• 1 page complicated construction design, 517 KB
• 320 page document reference document, 6.5 MB
• 14 page building design document, 6.5 MB

During this test we executed 87010 individual request sessions over 4 hours. The averages are as follows:

We saw behaviour similar to test #1 here but a slight increase in all resource usage. There is also a notable increase in network traffic.

Given this data, the server should be able to achieve levels exceeding 15 sessions per second with these types of documents. In this case, there is no main bottleneck for the system and improving any aspect of the server can increase the ability to handle requests.

This test will show how well WebViewer Server can handle a high stress load with documents that meet the following criteria:

• Exceed 100 MB in size
• High complexity drawing operations
• Many complicated pages

During this test we executed 5695 individual request sessions over 4 hours. The averages are as follows:

Similar to previous tests, we saw CPU and Memory rise together. However, we saw our network speed max out at 8 GB/s and our disk speed max out at around 5 GB/s.

Given this data, this server is already near its limits for this test due to a bottleneck in disk speeds. In order to improve performance in a scenario like this, we would recommend improving the following:

• The system disk performance
• The speed of the network
• The speed of the file server WebViewer Server is contacting

This test will show how well WebViewer Server can handle a collection of moderate to low impact non-PDF files. The file types of the documents used were: .DOC, .DWG, .XLSX, .XLS, .HTML, .PPTX, .DCM

• Lower than 100 MB in size
• Moderate to low conversion times

During this test we executed 23504 individual request sessions over 4 hours. The averages are as follows:

Similar to network usage write speed steadily climbed as job requests continued, but began to level off near the end. It reached a peak of around 1600 MB/minute.

Conversion compared to our atypical test did not push resource usage in the same way. Instead, conversion is subject to the longer processing times required to execute the tasks and a greater memory impact. The best way to improve performance with conversion is to increase the general speed of each individual hardware component to encourage faster processing times.

It is also possible to pre-convert your documents in order to remove the bottle neck of conversion times.

There are usually several core bottlenecks in WebViewer Server depending on the environment used.

The amount of available cores for processing on WebViewer Server will determine the number of concurrent jobs that can be performed. Increasing the core count in high stress situations can increase the number of concurrent jobs and increase overall performance.

Improving the overall speed and performance of the CPU will also result in faster renders and conversions.

WebViewer Server needs enough memory to perform its work as sometimes documents have large portions written directly to memory especially during conversions. Increased memory allows the in-memory cache to persist for longer increasing cache performance. Typically, if you are not exceeding your servers memory limit in daily usage it is likely enough memory for your setup.

The server uses a disk based cache in addition to it's in-memory cache and does significant disk writes and reads at every moment during a load. This means the server requires a performant disk. You may encounter problems using shared network disks, or using disks with read/write speeds below 100 MB/s even with lower loads. If you are encountering constant high load on your disk it likely means you need to upgrade.

Another source of slowdown for WebViewer Server is where it retrieves its source documents from. When a user 'passes' a URL to WebViewer Server is directly requesting the file. This means that WebViewer Server should be as close as possible to the source of the URL (the file server) to ensure it downloads file as fast as possible.

Slow network speeds can delay WebViewer Server from retrieving a document it's looking to process. This would greatly slow processing time for each document as we must wait for a file to be retrieved.