Compute Server

To use native PICTOFiT functionality like 2D or 3D try-on on the web, the compute server is required. It runs the algorithms for the different use cases and returns the results to the browser for displaying. Hosting of the compute server has to be done by the client. Reactive Reality doesn’t provide live instances. The following sections describe how to set it up and configure it.

Pull the compute server docker image

We will provide you with a deploy token which can be used to login to our public registry and pull images.

To authenticate to the Gitlab registry use the following command:

CODE

docker login -u <USERNAME> -p <TOKEN> registry.gitlab.com

You can then pull the latest compute server image from the registry.

We advise you to not use the latest tag, as that may cause compatibility issues with the Web SDK for upcoming releases! You may find the compatibility matrix here: Compatibility Matrix

CODE

docker pull registry.gitlab.com/reactivereality/public/registry/pictofitcore-web-computeserver:latest

Version Tags

We advise you to not use the latest tag but instead to pin a concrete version. All version tags have a v prefix meaning that e.g. version 1.2.3 can be found under

CODE

registry.gitlab.com/reactivereality/public/registry/pictofitcore-web-computeserver:v1.2.3

General configuration options

On startup, the server prints all configurable options to its log output. You may also find default values and possible options there.

After you successfully pulled the image from the registry you will not be able to run it. There are a few environment variables that can be set to configure the server.

Name	Description
`PORT`	The port on which the web server will be running inside the container.
`LOG_LEVEL`	Set the log level for the console output. Valid values are: `DEBUG`, `INFO` and `FATAL`.

Further options are available to configure your chosen Authentication method.

Download Caching 1.6.0

As of version v1.6.0 content behind provided asset urls is cached into a local caching storage. Before downloading an asset, the compute server will check the Content-MD5 header of the resource url and compare it against the local cache. If the checksum matches if one of the cached ones, it will reuse this file and just otherwise download it.

If no Content-MD5 is present, the url (instead of the checksum) will be cached for 24 hours. As a consequence the compute server will not notice any changes, and also not re-download to the file behind the url it during this timeframe.

Configuration

CACHE_SIZE_LIMIT_BYTES

The maximum amount of bytes the download disk cache should not surpass. When the limit is reached cached downloads will be evicted.

Response Caching 5.8.0

If response caching is enabled, the server will calculate a hash to identify the request and return a cached results if the same request was issued before and stored in cache. This can be useful for applications that happen to send repetitive requests and can significantly increase response times.

Configuration

`CACHE_RESPONSES_SIZE_LIMIT_BYTES`	The maximum amount of bytes the response disk cache should not surpass. When the limit is reached cached responses will be evicted.
`ENABLE_RESPONSE_CACHING`	If set to `true`, the compute server will cache computed responses and store them. To identify whether or not an incoming request was already calculated it uses a cherry picked version of the request.

Second layer cache

In a scaling environment where you have multiple instances handling requests at the same you might want to share pre-computed workloads among the servers. To do so you will need to enable second layer caching and specify a mounted directory where the shared cache can be stored. The second layer cache will only be read from to populate the session cache of an instance and only written to if there was a miss on the session and second layer cache.

Configuration

`ENABLE_SECOND_LAYER_RESPONSE_CACHE`	If set to `true`, the compute server will try to read and write to the second layer cache directory.
`ENABLE_SECOND_LAYER_RESPONSE_CACHE`	The shared cache directory / volume that was mounted into the container.

Health-check 4.5.0

As of version v4.5.0 a health check endpoint is available under /health. Use this endpoint to validate wether or not an instance needs to be restarted.

Run the compute server

Example with docker-compose.yml:

CODE

version: "3"
services:
  websdkcomputeserver:
    container_name: pictofit-computeserver
    image: registry.gitlab.com/reactivereality/public/registry/pictofitcore-web-computeserver:latest
    ports:
      - "${PORT}:${PORT}"
    env_file: .env
    restart: always

The .env file:

CODE

PORT=8000
AUTH_METHOD="public"
MEMORY_IN_MEGABYTES=1024

Boot the server up with: docker-compose up [--detach]

Usage with the SDK

The Pictofit Web SDK features a ComputeServer class that is dedicated to wrap the communication to all the endpoints of the Compute Server. This class is widely used in other higher level components like the provided IVirtualDressingRoom implementations.

Swagger 4.3.3

It might not always be possible to host the compute server at root level. Starting with version v4.3.3 you can set a custom base path by providing the API_BASEPATH environment variable.

The following sample assumes that you want to host the compute server under <URL>/rr/cs/. All you need to do now is to add the the following line to the .env file from above:

CODE

API_BASEPATH=/rr/cs/

This will make the swagger documentation available under <URL>/rr/cs/swagger/