Performance Benchmark

Meshery acts as a performance benchmark for multi-mesh performance comparison. Meshery incorporates the collection and display of metrics from applications running in the playground.


A service mesh playground to faciliate learning about functionality of different service meshes. Meshery incorporates a visual interface for manipulating traffic routing rules.



An engineer learns of the architecture and value provided by service meshes. Quite commonly, they are impressed and intrigued. Upon reflection, the most commonly asked question they then ask is “what overhead does being on the mesh incur?”.


Anytime performance questions are to be answered, they are subjective to the specific workload and infrastructure used for measurement. Given this challenge, the Envoy project, for example, refuses to publish performance data because such tests can be:

  1. involved
  2. misinterpreted
Beyond the need for performance and overhead data under a permutation of different workloads (applications) and types and sizes of infrastructure resources, the need for cross-project, apple-to-apple comparisons also desired in order to facilitate an of behavioral differences between service meshes and selection of their use. Individual projects shy from publishing test results of other, competing service meshes. An independent, credible analysis is needed.


In its current state, Meshery consists of the following components:

  1. Meshery SaaS
  2. Meshery SaaS plays a very minimalistic role in getting the user authenticated and persisting the results sent to it by the Meshery App.

  3. Meshery App
  4. Meshery App is the central component of Meshery. It deals with:

    1. redirecting users to Meshery SaaS to get them authenticated
    2. presenting the user interface to authenticated users
    3. accepts and maintains the Kubernetes cluster config and context info for the period of the session
    4. enables users to run load tests against their applications
    5. collects the results of the load tests from the load generator and passes it to Meshery SaaS
    6. interfaces with the Meshery adapters dynamically and enables the user to play with the service mesh

  5. Meshery Adapters
  6. Meshery adapters are the components which will be interfacing with the specific service meshes to apply the config changes requested through Meshery App. Meshery app will be interfacing with the relevant adapters over gRPC. The adapters will be running the gRPC server and the Meshery App will spin up the gRPC client as and when an operation is requested through the user interface. The proto buf spec is kept in the Meshery App so as to keep it in a central location. Today we have a functional adapter for Istio which is named meshery-istio. The adapters will be maintained in their own git repository. Source code for meshery-istio can be found here. We have also created a repository here for working with Linkerd 2.

  7. Load Generator
  8. For the load generator we are currently using Fortio.

Give Meshery a try

To run Meshery:

  1. On Kubernetes
    1. You can deploy Meshery to an existing kubernetes cluster using the provided yaml file into any namespace of your choice. For now let us deploy it to a namespace meshery:

        kubectl create ns meshery
        kubectl -n meshery apply -f deployment_yamls/k8s
        # additional step for running on Istio
        kubectl -n meshery apply -f deployment_yamls/istio.yaml

      If you want to use a different namespace, please change the name of the namespace in the ClusterRoleBinding section appropriately.

    2. Meshery can be deployed either on/off the mesh.

    3. If deployed on the same Kubernetes cluster as the mesh, you dont have to provide a kubeconfig file.

    4. please review the yaml and make necessary changes as needed for your cluster

  2. On Docker
    1. We have a docker-compose.yaml file which can be used to spin up the services quickly
    2. There a few requirements for running all the Meshery services on your local
      1. SSO, which uses Twitter and/or GitHub

        1. Instructions to setup Twitter for SSO can be found below
        2. Instructions to setup GitHub for SSO can be found below
      2. Add an entry for meshery-saas in your /etc/hosts file to point to and save the file

      3. After setting up SSO, store the respective key and secret as variables in the shell as shown below.

        1. for Twitter:
        1. for GitHub:

        Note: you can use Twitter and/or GitHub

        Now that the environment variables are setup, we can start the containers by running:

        docker-compose up

        Please add a -d flag to the above command if you want to run it in the background.

    3. Now you should be able to access Meshery in your browser at http://localhost:8080/play
Using Twitter for SSO
  1. Create an app in the Twitter developer console: after logging in.
  2. Fill appropriate details in the presented form
    1. Remember to enable to Sign in with Twitter
    2. For the callback url, please use this value: http://meshery-saas:9876/auth/twitter/callback
  3. After creating the app you will be able to grab the API key and secret from the Keys and tokens section of the app.
Using GitHub for SSO

  1. Create an OAuth app in the GitHub developer settings: after logging in.
  2. Fill appropriate details in the presented form
    1. For the callback url, please use this value: http://meshery-saas:9876/auth/github/callback
  3. After creating the app you will be able to grab the Client ID and Secret from the app page.


Fork me on GitHub This project is community-built and welcomes collaboration!

Benchmark Specification

The Benchmark Specification is a common format for describing and capturing performance benchmark tests and results. This specification is currently being advanced through discussion in the Meshery project.


      Why create Meshery and not use regpatrol?
      - regpatrol is not open source or available in binary form to use.
      What are some differences between regpatrol and Meshery?
      Telemetry - regpatrol sources telemetry from Mixer Prometheus adapter and uses IBM's proprietary node agent.
      - - Meshery sources from Mixer Prometheus adapter and uses Prometheus node-exporter.
      Traffic type - regpatrol uses jmeter, which can parse responses and perform functional tests.
      - - Meshery is using fortio, which is for load-gen and perf-testing only.
      Why use Meshery?
      - because its an open source, vendor neutral projects that facilitates testing across meshes.
      - because fortio is not packaged into a mesh testing utility, but is only a load-generator unto its own.
      - because regpatrol is closed sourcej, binary is not released, scripted for one mesh, and is produced by a vendor of that mesh.

Mailing List

Stay up-to-date on service mesh content...