Performance
谁动了我的 CPU 频率 —— CPU 性能之迷 Part 2
· ☕ 20 分钟
很多人知道 CPU 频率会影响 CPU 性能,也知道频率会动态变化,且知道 Linux 有 performance/powersave 两种频率控制策略。但很少人知道背后的软件原理,更少人知道如何调优策略,和监控实际 CPU 频率。

Java 容器化的历史坑(史坑) - 资源限制篇
· ☕ 5 分钟

由来

时间回到 2017 年,老东家要上 Kubernetes 了,有幸参与和学习(主要是学习)。当时遇到的一了所有 Java 容器化者都遇到的坑:JDK8 不为容器化设计综合症。最简单的例子是Runtime.getRuntime().availableProcessors()返回了主机的 CPU 数,而非期望的容器自身的cpu share/quota,或说 k8s 的 cpu request/limit


你的 Istio Mesh 性能及格吗?
· ☕ 4 分钟

image-20210601224250230

前言

话说,一年前项目响应时代的号召,引入了 Istio,从此如刘备得卧龙、凤雏,走上了 Service Mesh 的光辉大道。现到准备益州之战(上线)之时。上线前,还得评估一下性能变化。


Benchmark Tools
· ☕ 1 分钟

CPU Benchmark

The SysBench system benchmark suite has a simple CPU benchmark tool that calculates prime numbers. For example:

# sysbench --num-threads=8 --test=cpu --cpu-max-prime=100000 run
sysbench 0.4.12:  multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 8

Doing CPU performance benchmark

Threads started!
Done.

Maximum prime number checked in CPU test: 100000

Test execution summary:
    total time:                          30.4125s
    total number of events:              10000
    total time taken by event execution: 243.2310
    per-request statistics:
         min:                                 24.31ms
         avg:                                 24.32ms
         max:                                 32.44ms
         approx.  95 percentile:              24.32ms

Threads fairness:
    events (avg/stddev):           1250.0000/1.22
    execution time (avg/stddev):   30.4039/0.01

This executed eight threads, with a maximum prime number of 100,000. The runtime was 30.4 s, which can be used for comparison with the results from other systems or configurations (assuming many things, such as that identical compiler options were used to build the software; see Chapter 12, Benchmarking).