Sneak Preview: Improve Performance Using a Read-only Instance

By Eskil - May 17, 2016 (Last updated: April 9, 2017)

Besides clustering for high availability, we are also working on supporting clustering to improve performance. Vidispine 4.6 will support setting up read-only instances, possibly connected to asynchronous database read replicas or database snapshots, to expose a read-only API.

Since Vidispine 4.1 is has been possible to set up Vidispine in a cluster configuration, using either clustered GlassFish instances or since 4.2, a native cluster. The cluster is typically set up together with a load balancer such a HAProxy and a database running with master-master replication or master-slave with failover, to create a high-availability cluster configuration.

In 4.6 it will be possible to set up read-only Vidispine instances, that only expose GET and certain PUT methods from the API. A read-only instance can be connected to either the master database, an asynchronous read replica or a database snapshot.
4.6 read-only Vidispine illustration
Compared to a clustered instance, where any instance could serve any request with identical results, a read-only instance is expected to be connected to a database that either uses asynchronous replication, where a certain replication lag is to be expected, or a database that is not receiving updates at all. It is thus not an alternative to a cluster for high availability purposes, but an option for improved performance for applications expecting heavy load with many reads, e.g. publishing search results or applications that need to extract metadata for reporting purposes for example.

Read-only mode is enabled in the service configuration file server.yaml:

  type: master/read_only_replica/read_only_snapshot

A read-only instance is not a member of the cluster, so it will not execute any cluster-wide tasks nor receive any cache invalidation events. The application has full flexibility to choose to query the master/clustered Vidispine instance or any read-only instances. The replica lag metric from the database and the index lag metric from VS can be used to determine how suitable an instance is.

See also: