本篇介绍和Istio性能关系较大的几个参数。仅供参考。
1.keepaliveMaxServerConnectionAge
这是Helm部署参数。它控制的是这是参数控制sidecar连接Polit的最长时间。在Isiot1.1中，默认时间是30分钟。
我们知道，在istio中，sidecar是要和Polit进行通讯的。Polit的实例数量通常不止一个。这就带来一个问题：如果Istio的访问量突然增大，Polit启动HA，sidecar什么时候连接到新的Polit？
keepaliveMaxServerConnectionAge参数如果设置的太小，可能会造成访问流量的丢失（sidecar与Polit的重链接频繁），如果设置的太大，将会造成Polit负载不均衡。
目前关于这个参数的设置，社区里也做过一些测试，有开发者设置为6分钟。具体的设置数值，需要根据自身Istio的情况进行测试后获得。
目前在OpenShift上安装Istio，由于采用Operator的方式，这个参数的调整未开放。后续Istio on OCP有开放的可能。
2. global.proxy.concurrency
这是Helm部署参数。它控制Proxy worker的线程数量。它会影响sidecar的资源利用率和延迟。模式数值是2
这点其实好理解，我们给sidecar分配的cpu计算能力越强，它的性能就会越好、资源消耗会越大、应用延迟会月底。
如果将global.proxy.concurrency设置为0，也就是说，每个Proxy worker线程占用一个CPU core（如果打开CPU超线程，就是占用CPU硬件超线程）。默认数值是2，也就是说，两个Proxy worker的线程共享一个CPU core（如果打开CPU超线程，就是占用CPU硬件超线程）。
目前在OpenShift上安装Istio，由于采用Operator的方式，这个参数的调整未开放。后续Istio on OCP有开放的可能。
3.global.enableTracing
这是配置参数。可以通过configmap进行配置，然后重启pilot后生效。这个参数默认是关闭的。
启动tracing会造成大量的资源开销并影响吞吐量。Tracing的provider是jaeger。
生产环境建议disable此参数。
基于Openshift的istio可以调整此参数。
4.Telemetry和Gateways HPA阈值
这是配置参数。它会影响istio的性能。在规模较小的Istio环境中，Gateway和Telemetry的HPA可以关闭（Istio On OCP默认是关闭的）。在基于OpenShift的istio中，HPA是否打开取决于如下参数：
参数具体设置如下：
CPU 资源的基本单位是 millicores，因为 CPU 资源其实准确来讲，指的是 CPU 时间。所以它的基本单位为 millicores，1 个核等于 1000 millicores。也代表了 kubernetes 可以将单位 CPU 时间细分为 1000 份，分配给某个容器。Resources代表Telemetry pod request的CPU和和内存，limit代表Telemetry pod最多使用的cpu和内存。Resources 1000m代表一个cpu core。而CPU最多使用4800，也就是4.8core。
HPA逻辑如下
- 收集该HPA控制下所有Pod最近的cpu使用情况（CPU utilization）
- 对比在扩容条件里记录的cpu限额（CPUUtilization）
- 调整实例数（必须要满足不超过最大/最小实例数）
- 每隔30s做一次自动扩容的判断
说明：
- CPU utilization的计算方法是用cpu usage（最近一分钟的平均值，通过heapster可以直接获取到）除以cpurequest（这里cpu request就是我们在创建容器时制定的cpu使用核心数）得到一个平均值，这个平均值可以理解为：平均每个PodCPU核心的使用占比。
- 最重要的步骤为3，这里即为HPA的算法，计算当前需要启动几个Pod
如果我们将Resources设置的太高，那么Telemetry和Gateways 扩容几乎应用不会发生，这就失去了HPA的意义，也浪费资源。如果设置的太低，频繁发生扩缩容，会降低istio的稳定性。Telemetry的ResourcesCPU和内存可以适当调小。
如果我们启用了Gateways 隔离，也可以将它的ResourcesCPU和内存可以适当调小。
此外，我们还可以配合OpenShift的limitrange、qouta等参数使用。为重要的组件预留更多的资源，对不太重要的组件限制资源。具体的数值要根据自身的情况进行测试验证。OCP的几个参数基本概念就不再赘述了。
