Porque é que o seu novo servidor mede pior do que o antigo, quando não é mais lento.

Uma pergunta comum depois de uma migração é se um valor de bogomips mais baixo significa um servidor mais lento. Não significa. Eis como lhe respondemos.

O número por trás da pergunta

Tinha comparado o bogomips na máquina antiga e na nova, e o valor novo veio mais baixo. Lido à letra, parece um downgrade. Não é, e para perceber porquê é preciso saber o que é esse número.

$ grep -m1 bogomips /proc/cpuinfo

O que o bogomips mede realmente

O bogomips não é um benchmark. É um ciclo de calibração que o kernel corre uma vez no arranque para dimensionar os seus próprios atrasos internos de temporização, de modo a saber aproximadamente quantos busy-loops cabem num dado intervalo. O nome é uma piada que os programadores do kernel fizeram à própria custa: bogus millions of instructions per second. Num host virtualizado o número é mais bogus do que o habitual, porque reflete o relógio apresentado ao guest, o valor que o hypervisor entrega à VM, enquanto o núcleo físico por baixo continua a correr em turbo máximo. Um valor de bogomips mais baixo é uma peculiaridade da forma como a virtualização expõe o relógio, não a perda de nada real.

“O bogomips não mede nada que quisesse comprar.”

O indicador indireto contra o trabalho real

Toda a discussão do tipo «o meu servidor ficou mais lento» é na verdade uma disputa sobre o que escolheu medir. Ponha o indicador ao lado do trabalho e a disputa acaba.

Meça o trabalho, não o indicador

A jogada perdedora é dizer que o bogomips não significa nada e ficar por aí, porque pede a um cliente que troque o seu número pela nossa palavra. Por isso fizemos o contrário. Dissemos o que o bogomips mede realmente, e depois entregámos-lhe os benchmarks para correr ele próprio: cargas criptográficas e de CPU reais, do tipo que representa o que uma aplicação faz de facto. Acrescentámos uma nota. A geração de processador mais recente por baixo da VM dele é mais rápida, com instruções mais largas, por isso o trabalho real muito provavelmente sairia à frente, não atrás.

# stop measuring the proxy. measure the work.
$ openssl speed -evp aes-256-gcm          # cryptographic throughput
$ sysbench cpu --cpu-max-prime=20000 run  # raw CPU work
# run on the old box and the new one, then compare the work, not the clock.

A lição

Uma medição vale o que realmente mede. Quando um cliente chega com um indicador indireto, a jogada não é discutir o número. É dizer o que o número mede realmente, e depois deixar o trabalho real decidir. A máquina por baixo esteve calma e rápida o tempo todo. A única coisa que ficou mais lenta foi o benchmark.