Então … cache. O que é isso? É uma maneira de obter uma recompensa rápida, não recalculando ou buscando coisas repetidamente, resultando em ganhos de desempenho e custo. É mesmo daí que vem o nome, é uma forma abreviada de “ca-ching!” som de caixa registradora da idade das trevas de 2014, quando a moeda física ainda era uma coisa, antes do Apple Pay. Agora sou pai, lide com isso.

Digamos que precisamos chamar uma API ou consultar um servidor de banco de dados ou apenas pegar um bilhão de números (o Google diz que é uma palavra real , eu verifiquei) e somá- los. Esses são todos relativamente louco caro. Portanto, armazenamos o resultado em cache – o mantemos à mão para reutilização.

 

Por que fazemos cache?

 

Eu acho que é importante discutir aqui o quão caro algumas das coisas acima são. Existem várias camadas de armazenamento em cache em seu computador moderno. Como um exemplo concreto, vamos usar um de nossos servidores web, que atualmente hospeda um par de CPUs Intel Xeon E5-2960 v3 e DIMMs de 2133 MHz. O acesso ao cache é um recurso de “quantos ciclos” de um processador, portanto, sabendo que sempre rodamos a 3,06 GHz (modo de potência de desempenho), podemos derivar as latências ( referência da arquitetura Intel aqui – esses processadores estão na geração Haswell):

 

L1 (por núcleo): 4 ciclos ou latência de ~ 1,3 ns – 12x 32 KB + 32 KB

 

L2 (por núcleo): 12 ciclos ou latência de ~ 3,92 ns – 12x 256 KB

 

L3 (compartilhado): 34 ciclos ou latência de ~ 11.11ns – 30 MB

 

Memória do sistema: latência de ~ 100ns – 8x 8 GB

 

Cada camada de cache pode armazenar mais, mas está mais distante. É uma troca no design do processador com equilíbrios em jogo. Por exemplo, mais memória por núcleo significa (quase certamente) em média colocá-la mais longe do núcleo no chip, e isso tem custos de latência, custos de oportunidade e consumo de energia. A distância que os elétrons precisam percorrer tem um impacto substancial nessa escala; lembre-se de que a distância é multiplicada por bilhões a cada segundo.

E não entrei na latência de disco acima porque raramente tocamos no disco. Por quê? Bem, acho que para explicar que precisamos … olhar para os discos. Ooooooooh discos brilhantes! Mas, por favor, não toque neles depois de andar por aí de meias. No Avance Network, qualquer produção que não seja um servidor de backup ou registro está em SSDs. O armazenamento local geralmente se enquadra em alguns níveis para nós:

 

 

NVMe SSD: ~ 120μs ( fonte )

 

SATA ou SAS SSD: ~ 400–600μs ( fonte )

 

HDD rotacional: 2–6ms ( fonte )

 

Esses números estão mudando o tempo todo, então não se concentre muito em números exatos. O que estamos tentando avaliar é a magnitude da diferença dessas camadas de armazenamento. Vamos analisar a lista (assumindo o limite inferior de cada um, esses são os números do melhor caso):

 

L1: 1,3 ns

 

L2: 3,92ns ( 3x mais lento )

 

L3: 11,11 ns ( 8,5x mais lento )

 

RAM DDR4: 100ns ( 77x mais lento )

 

NVMe SSD: 120.000ns ( 92.307x mais lento )

 

SATA / SAS SSD: 400.000 ns ( 307.692x mais lento )

 

HDD rotacional: 2–6ms ( 1.538.461x mais lento )

 

Login do Microsoft Live: 12 redirecionamentos e 5s ( 3.846.153.846x mais lento , aproximadamente)

 

Se os números não são sua praia, aqui está uma visualização de código aberto bacana (use o controle deslizante!) Por Colin Scott (você pode até ver como eles evoluíram ao longo do tempo – realmente bacana):

 

 

Com esses números de desempenho e um senso de escala em mente, vamos adicionar alguns números importantes todos os dias. Digamos que nossa fonte de dados esteja X, onde o que X está não importa. Pode ser SQL, ou um microsserviço, ou um macrosserviço, ou um serviço do teclado esquerdo, ou Redis, ou um arquivo em disco, etc. A chave aqui é que estamos comparando o desempenho dessa fonte com o da RAM. Digamos que nossa fonte pegue…

 

100ns (da RAM – rápido!)

 

1ms (10.000x mais lento)

 

100ms (100.000x mais lento)

 

1s (1.000.000x mais lento)

 

Não acho que precisamos ir mais longe para ilustrar o ponto: mesmo as coisas que levam apenas 1 milissegundo são muito, muito mais lentas do que a RAM local . Lembre-se: milissegundo, microssegundo, nanossegundo – apenas no caso de alguém esquecer que 1000ns! = 1ms como eu às vezes faço…

Mas nem todo cache é local. Por exemplo, usamos Redis para armazenamento em cache compartilhado por trás de nossa camada da web ( que abordaremos em breve) Digamos que estamos cruzando nossa rede para obtê-lo. Para nós é uma viagem de ida e volta de 0,17ms e você também precisa enviar alguns dados. Para coisas pequenas (nosso usual), isso vai ser em torno de 0,2–0,5 ms no total. Ainda 2.000–5.000x mais lento do que a RAM local, mas também muito mais rápido do que a maioria das fontes. Lembre-se de que esses números são porque estamos em uma pequena LAN local. A latência da nuvem geralmente será maior, então meça para ver sua latência.

Quando obtemos os dados, talvez também queiramos massagear de alguma forma. Provavelmente sueco. Talvez precisemos de totais, talvez precisemos filtrar, talvez precisemos codificá-los, talvez precisemos modificá-los aleatoriamente apenas para enganar você. Foi um teste para ver se você ainda está lendo. Você passou! Seja qual for o motivo, a semelhança é geralmente o que queremos fazer x uma vez , e não cada vez que o servimos.

Às vezes, economizamos latência e às vezes economizamos CPU. Geralmente, um ou ambos são o motivo pelo qual o cache é introduzido. Agora vamos cobrir o outro lado …

 

Por que não armazenaríamos em cache?

 

Para todos que odeiam cache, esta seção é para você! Sim, estou totalmente jogando dos dois lados.

Dado o exposto acima e quão drásticas são as vitórias, por que não armazenaríamos algo em cache? Bem, porque cada decisão tem vantagens e desvantagens . Cada. Solteiro. 1. Pode ser tão simples quanto tempo gasto ou custo de oportunidade, mas ainda há uma compensação.

 

Quando se trata de cache, adicionar um cache acarreta alguns custos:

 

 

 

Purgar valore