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.
Notes
Language
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.
About the environment
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.
Performance in practice
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
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_MBwhich is set to 50000 MB
Test scenarios
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.
Test 1 - Small PDF documents
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:
88077
14 ms
146 ms
1003 ms
6.11
CPU Usage
Memory Usage
Disk Usage
Network
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.
Test 2 - Typical PDF documents
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:
84337
69 ms
227 ms
1013 ms
5.8
CPU Usage
Memory Usage
Disk Usage
Network Usage
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.
Test 3 - Atypical PDF documents
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:
5606
298 ms
2283 ms
5420 ms
0.38
CPU Usage
Memory Usage
Disk Usage
Network Usage
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
Test 4 - Non-PDF documents
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:
23504
87 ms
1038 ms
2006 ms
1.6
CPU Usage
Memory Usage
Disk Usage
Network Usage
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.
Overall conclusion
1
88077
14 ms
146 ms
1003 ms
6.11
2
84337
69 ms
227 ms
1013 ms
5.80
3
5606
298 ms
2283 ms
5420 ms
0.38
4
23504
87 ms
1038 ms
2006 ms
1.6
Understanding bottlenecks
There are usually several core bottlenecks in WebViewer Server depending on the environment used.
CPU & CPU core count
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.
Memory
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.
Disk
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.
Network
File server source downloads
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
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.
Last updated
Was this helpful?