Requirements#

Supported platforms and operating systems#

The Visionect Server is distributed either as native packages for Ubuntu 14.04 LTS or as a VirtualBox virtual machine, which can be run in Windows, OSX and Linux (either with VirtualBox or Vagrant). The VirtualBox virtual machine is primarily meant as a development tool, while production deployments should be done as native packages under Ubuntu for performance reasons.

If you’re looking to run Visionect Server under other Linux distributions, then Docker is the way to go. It provides minimal overhead in environments where it is not possible to run Ubuntu Server natively. Official Docker support is currently in beta and Docker images are available upon request.

The Visionect Server runs a WebKit browser session for each device. WebKit sessions are similar to your desktop web browser tabs - you can run a lot of them as long as you have enough memory. This means that the key factor in determining server capacity is the available memory, followed by CPU and lastly the available hard drive space.

Memory#

Server memory requirements depend on a number of factors, such as the number of devices, device type (screen size), server version, running app and update frequency.

The base system requires at least 500 MB of memory for all services. Each device then requires an additional 150-400 MB of memory for its server session. Memory usage is tightly connected with screen usage, so devices with small screens will work around the bottom end of this limitation. Memory consumption is not static - it shoots up during the session instantiation and then tapers down to a stable state. Any memory leaks that are caused by WebKit are prevented by periodic session memory checks that restart offending processes.

Note

Typical memory usage examples:

  • Visionect 6’’ Signs (1024x758 pixels) = 150-200 MB

  • Place&Play 32” (2560x1440 pixels) = 600-700 MB.

Note

The Visionect Software Suite size estimation and planning formula is as follows:

1 GB + [number of devices]*[estimated use per device] = [memory usage requirement estimate]

It is also possible to calculate a general estimation of the Software Suite site for your specific use-case, using the following form:

Number of devices * your Web Session Memory Limit + 1 GB (system requirements)

Plus, you can always a add few additional GBs, to be on the safe side. For example, a use-case of 32 devices with a Web Session Limit at 200 MB would require around 8 - 12GB.

Note

The Current Web Session Memory Limit setting in set in the Visionect Software Suite. Go to Settings -> HTML Backend -> Web Session Memory Limit.

The production servers should always have SWAP enabled to handle spikes in memory consumption (otherwise you will hit your memory limit sooner). To enable it you can follow the guide on Digital Ocean.

Memory usage reduction#

If memory is a concern, you can switch to the HTTP push backend where images are pushed directly to the frame buffer. Here, the the requirements are reduced for an order of magnitude - a ballpark figure would be 20MB per 1024*758 device.

The frame buffer is not stored in 4bit grayscale but in full RGB, so that content can be optimized for the display (in terms of contrast, color, etc). At least two frame buffers (the current and the previous one) are needed to optimize content for transmission. The images are not compressed due to performance reasons, plus there is also some overhead.

Hard drive#

While the Visionect Software Suite itself does not require a lot of disk space, logging facilities will be more space-consuming in the long run. Some of the logging can be disabled and the logs are rotated by default (except of a couple of specific files such as device-events). Nevertheless, the amount of space used can be non-trivial. Additionally, the Visionect Software Suite also logs each event (click, image change, signal strength reading…) in its storage backend (PostgreSQL by default). When deploying the system in production, users should think about how many of these past events you will require for later analysis.

As an example, a server which hosts 25 devices and runs a very interactive application (guests using devices to order food and drinks - a lot of clicks) will generate about 4.5GB of events in six months.

Reducing log level of Visionect Software Suite#

In general, all the logs should rotate by default, except a couple of specific files (such as device-events, device_status_messages etc.). Reducing logging level can be done by editing special configuration (.conf) files (for all services that stars) which reside in /etc/supervisor/conf.d/ folder.

It is possible to reduce the verbosity of logs by editing configuration files in /etc/supervisor/conf.d/*.conf. To do this, add the flag -d 1 to the command line (example: command=/opt/visionect/koala2/bin/{component name} -d 1). In Network Manager’s case (/etc/supervisor/conf.d/networkmanager.conf), it is also possible to stop logging all the device status messages to an external file; this can be done by removing the -e flag from the command line.

An additional CLI flag is available in the Network Manager: flag -s for setting status filtering (disabled by default). When provided with a parameter, it will tell the Suite which status report from the device to acknowledge. For example, the setting -s=10 will accept only the 10th status report and disregard the rest. By using this flag, users can filter and consequently reduce log level of the Suite even further.

As an alternative method, users can also create a cron script which will compress the logs daily/weekly/monthly for later analysis if needed.

Finally, it is also possible to set the logs to auto-rotate by adding the right directives. More details are avialable at: http://supervisord.org/configuration.html#program-x-section-settings.

Processors#

As explained before, the Visionect Software Suite is mostly memory-bound. We’ve run 100 very interactive devices in a stress test (1 interaction per second per device) on a modern quad core processor, and it performed without any serious glitches. If your CPU utilization is very high, you’re more likely to run into issues caused by low memory and the hard drive swapping caused by it.