11 Performance-tuning the control plane

 

This chapter covers

  • Understanding the factors of control-plane performance
  • How to monitor performance
  • What are the key performance metrics
  • Understanding how to optimize performance

In the previous chapter on troubleshooting the data plane, we took a deep dive into the debugging tools available to diagnose issues with proxy configuration and proxy behavior. Understanding the service proxy configuration simplifies troubleshooting when behaviors do not match our expectations.

In this chapter, we focus on optimizing control-plane performance. We investigate how the control plane configures the service proxies, the factors that slow down this process, how to monitor it, and the knobs we can turn to improve performance.

11.1 The control plane’s primary goal

In previous chapters, we’ve said that the control plane is the brains of the service mesh and that it exposes an API for service-mesh operators. This API can be used to manipulate the behavior of the mesh and configure the service proxies deployed alongside each workload instance. What we omitted for brevity is that service mesh operators—that is, us—making requests to this API is not the only way the mesh’s behavior and configuration are affected. More generally, the control plane abstracts away details of the run-time environment such as what services exist (service discovery), which services are healthy, autoscaling events, and so on.

11.1.1 Understanding the steps of data-plane synchronization

11.1.2 Factors that determine performance

11.2 Monitoring the control plane

11.2.1 The four golden signals of the control plane

11.3 Tuning performance

11.3.1 Setting up the workspace

11.3.2 Measuring performance before optimizations

11.3.3 Ignoring events: Reducing the scope of discovery using discovery selectors

11.3.4 Event-batching and push-throttling properties

11.4 Performance tuning guidelines

Summary

sitemap