> For the complete documentation index, see [llms.txt](https://docs.apryse.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.apryse.com/web/webviewer-server/wv-server-performance.md).
# WebViewer Server Performance
Discover the expected performance benchmarks of WebViewer Server across different scenarios. Evaluate your deployment with insights on run time, queue time, request duration, and bottlenecks. Enhance
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_MB` which 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:
| Sessions | Average Run time | Average Queue time | Average Session time | Sessions/second |
| -------- | ---------------- | ------------------ | -------------------- | --------------- |
| 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:
| Sessions | Average Run time | Average Queue time | Average Session time | Sessions/second |
| -------- | ---------------- | ------------------ | -------------------- | --------------- |
| 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:
| Sessions | Average Run time | Average Queue time | Average Session time | Sessions/second |
| -------- | ---------------- | ------------------ | -------------------- | --------------- |
| 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:
| Sessions | Average Run time | Average Queue time | Average Session time | Sessions/second |
| -------- | ---------------- | ------------------ | -------------------- | --------------- |
| 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
| Test | Sessions | Average Run time | Average Queue time | Average Session time | Sessions/second |
| ---- | -------- | ---------------- | ------------------ | -------------------- | --------------- |
| 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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.apryse.com/web/webviewer-server/wv-server-performance.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.