Some test text!
WebViewer Server manages its own work queues and caches a lot of intermediate data opportunistically locally, both in RAM and on disk. As such, having access to more system resources will allow the Server to operate more responsively and efficiently (using cached data improves response time, and also conserves CPU resources).
If your use case calls for multiple backend nodes, then a smaller number of more capable nodes is a better choice than a large umber of smaller nodes -- a 4 core/8GB server will have a higher peak user capacity than two 2 core/4GB servers.
In order to maintain efficient operation, WebViewer server requires access to at least 2 CPU cores, at least 2GB of RAM, and 50GB of storage space. Anything less than 2 cores, and internal work queues will start to behave serially, which will drastically raise server response times.
Access to insufficient RAM limits the amount of data that can be held in the short-term cache, and it also limits the ability of the server to process particularly difficult documents.
If there is insufficient storage space, then the server will be unable to generate data without first pushing out existing cached data that is still in use by clients.
The WebViewer server comes with a self-signed certificate, usable for SSL debugging purposes only.
In order to have SSL work correctly on your own domain you must provide a certificate chain file. This certificate chain file should:
Once the key is prepared you should:
haproxy/directory in the root directory.
SSL_CHAINvariable to the name of the certificate chain file in the
The container (along with webviewer) now has built-in support for using multiple backends behind a load balancer.
As the container is not entirely stateless, the balancer needs to fulfill a few requirements:
There is a sample configuration included in the download archive which demonstrates a fully working load balancer setup. Running
docker-compose -f docker-compose_load_balance.yml up will launch a container composed of two WebViewer Server nodes with an HAProxy load balancer front end.
In the sample setup, incoming connections are directed to the least occupied backend node, and will remain attached to that node for the remainder of the session, or until the node starts to become overloaded.
If there are no available healthy nodes, then WebViewer will attempt to continue in client-only rendering mode.
Server configuration is most easily done via
docker-compose.yml, located in the root of the downloadable WebViewer server distribution. server environment variables can be set directly within that file.
It is possible to map the statically served data generated by the container to an external volume. The external folder must be granted full write access. See the commented out
volumes: sections in both
Please be aware that the performance of this volume is critical to the performance of the server in general, and that the server operates under the assumption that the files will not be modified or locked by another process.
To access the server from a different internal URL, adjust the
URL_PREFIX options in
docker-compose.yml. For example, with the option value
URL_PREFIX: custom-prefix, the demo would be available at http://localhost:8091/custom-prefix/demo/?s
In order to adjust the capabilities of the built container, please see the following options in
INCLUDE_DEMO. Turning these options off will result in smaller built container.
If the server container has the environment variable
TRN_FETCH_DEFAULT_BASE_ADDR set, then the url argument can start with a slash, in which case it will be appended to
TRN_FETCH_DEFAULT_BASE_ADDR before fetching.
Setting the environment variable
TRN_DISABLE_CLIENT_PDF_ACCESS will prevent the server from sending the PDF directly to the client, preferring other display modes instead (like server-side image rendering or .xod). Intended to protect sensitive documents by ensuring that only derived data (like rendered pages) are ever sent to the client.
setting the environment variable
TRN_DEBUG_DISABLE_CLIENT_BACKEND_SWITCH in the server container will cause webviewer to stick with the server-rendering image backend and not switch to a more efficient client side option at any point. This option is for debugging only, as it may be removed in a future version.
If the environment variable
TRN_FETCH_DOWNGRADE_HTTPS is set, then all fetches originating from the docker server will be made as http, rather than https.
During the course of normal operation, WebViewer server will generate content static content like rendered pages or document metadata and make it accessible to clients via an obfuscated URI. While this link is unguessable, it is not access-limited by default -- if a client shares or leaks the link, it could be accessible by third parties. If this is a concern, the environment variable
TRN_ENABLE_SESSION_AUTH can be set. This will ensure that these URL are only to clients with currently connected WV sessions. This will add a small amount of overhead to each connection, and hinder the viewing of thumbnails in the demo application.