{"id":2088,"date":"2015-10-22T14:57:23","date_gmt":"2015-10-22T14:57:22","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=2088"},"modified":"2022-12-15T19:21:14","modified_gmt":"2022-12-16T03:21:14","slug":"all-the-small-things-jvm-profiling-lessons-from-the-trenches","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/pt\/all-the-small-things-jvm-profiling-lessons-from-the-trenches\/","title":{"rendered":"Todas as pequenas coisas - Li\u00e7\u00f5es de cria\u00e7\u00e3o de perfil de JVM das trincheiras"},"content":{"rendered":"

JMH (Java Microbenchmarking Harness)<\/a> tornou-se uma das minhas ferramentas mais valiosas para quantificar (e, em \u00faltima an\u00e1lise, justificar) uma otimiza\u00e7\u00e3o de desempenho dentro do Couchbase Java SDK e seus projetos relacionados. Como vejo muitos usu\u00e1rios e clientes tendo dificuldades com quest\u00f5es semelhantes, achei que seria uma boa ideia mostrar como voc\u00ea pode usar o JMC (Java Mission Control)<\/a> em combina\u00e7\u00e3o com o JMH para orientar suas decis\u00f5es de teste de otimiza\u00e7\u00e3o de desempenho de perfil e JMC usando dados reais em vez de suposi\u00e7\u00f5es.<\/p>\n

Voc\u00ea pode simplesmente ler e examinar o c\u00f3digo-fonte ao lado, mas se quiser reproduzir o que vou mostrar, precisar\u00e1 de um Oracle JDK recente (para o JMH, estou usando o 1.8.0_51). Al\u00e9m disso, n\u00e3o mostrarei todos os detalhes menores, como importar um projeto para seu IDE ou algo semelhante. Se voc\u00ea tiver dificuldades com os conceitos b\u00e1sicos de cria\u00e7\u00e3o de perfil de desempenho do Java, esta publica\u00e7\u00e3o provavelmente n\u00e3o \u00e9 para voc\u00ea imediatamente.<\/p>\n

O problema com a maioria dos aplicativos e bibliotecas reais \u00e9 que n\u00e3o h\u00e1 nenhum problema \u00f3bvio. Se voc\u00ea encontrar algo, der um tapinha nas costas e for consert\u00e1-lo, essas chances s\u00e3o raras. Muitas vezes, voc\u00ea precisa fazer v\u00e1rios pequenos aprimoramentos para obter melhores resultados. No Java SDK, n\u00f3s nos preocupamos em aumentar a taxa de transfer\u00eancia e, ao mesmo tempo, minimizar a lat\u00eancia o m\u00e1ximo poss\u00edvel. Como essas duas propriedades n\u00e3o se amam particularmente, h\u00e1 apenas algumas coisas que voc\u00ea pode fazer para que ambas fiquem mais felizes ao mesmo tempo:<\/p>\n

    \n
  1. Reduzir a quantidade de CPU que seu aplicativo precisa para fazer c\u00e1lculos<\/li>\n
  2. Minimizar a conten\u00e7\u00e3o e os pontos de sincroniza\u00e7\u00e3o<\/li>\n
  3. Evite aloca\u00e7\u00f5es de objetos para que o GC fa\u00e7a menos<\/li>\n<\/ol>\n

    Neste exemplo, voc\u00ea ver\u00e1 o n\u00famero 3 (e um) em a\u00e7\u00e3o. Estou executando o seguinte c\u00f3digo no projeto core-io:<\/p>\n

    Se voc\u00ea j\u00e1 assistiu a algumas de minhas palestras, sempre digo \u00e0s pessoas que algo assim n\u00e3o \u00e9 um benchmark adequado - ent\u00e3o por que fa\u00e7o isso aqui? A grande diferen\u00e7a \u00e9 que, como usu\u00e1rio, voc\u00ea est\u00e1 fazendo um benchmark do Couchbase como um todo, essa n\u00e3o \u00e9 uma carga de trabalho realista que imita o seu sistema de produ\u00e7\u00e3o. Como desenvolvedor de bibliotecas, quero encontrar caminhos de c\u00f3digo quentes e torn\u00e1-los mais r\u00e1pidos, portanto, executar o mesmo c\u00f3digo repetidamente exp\u00f5e melhor esses caminhos no profiler da JVM (Java).<\/p>\n

    Quando executo esse c\u00f3digo em meu n\u00f3 local do Couchbase Server, obtenho cerca de 9 mil opera\u00e7\u00f5es\/s. N\u00e3o estou interessado em aumentar a taxa de transfer\u00eancia neste momento, estou tentando reduzir as aloca\u00e7\u00f5es de objetos no caminho do c\u00f3digo quente em primeiro lugar. Ao iniciar o JMC e apont\u00e1-lo para a minha JVM por meio do JFR (Java Flight Recorder) e, em seguida, deixar a m\u00e1quina sozinha por 5 minutos enquanto fa\u00e7o o perfil, obtive o seguinte:<\/p>\n

    <\/p>\n

    H\u00e1 400 MB alocados em 5 minutos para objetos KeyValueStatus[]. Isso pode n\u00e3o ser \u00f3bvio para voc\u00ea, mas sei que recentemente alteramos algo nesse caminho de c\u00f3digo (consulte aqui<\/a>) e nunca vi esse tipo espec\u00edfico de aloca\u00e7\u00e3o aparecer antes. Ap\u00f3s uma r\u00e1pida investiga\u00e7\u00e3o, ficou claro que o suspeito est\u00e1 no seguinte caminho de c\u00f3digo (observe como o JFR nos guia para o lugar certo):<\/p>\n

    Toda vez que chega uma resposta, n\u00f3s a comparamos com o enum KeyValueStatus para definir o status de resposta adequado. Um dos meus colegas fez com que o c\u00f3digo ficasse bonito durante a refatora\u00e7\u00e3o, mas tamb\u00e9m introduziu sutilmente a sobrecarga de GC. Como mostram as informa\u00e7\u00f5es de cria\u00e7\u00e3o de perfil, values() sempre cria uma matriz para que possamos iterar sobre ela e encontrar o c\u00f3digo correspondente. N\u00e3o \u00e9 muito, mas vai se acumulando com o tempo. Mas o mais importante: \u00e9 um lixo desnecess\u00e1rio.<\/p>\n

    Acontece que algumas respostas s\u00e3o (muito) mais prov\u00e1veis de acontecer do que outras, portanto, podemos otimizar para o caso comum (sempre uma boa ideia). N\u00e3o vou aborrec\u00ea-lo com todos os detalhes de baixo n\u00edvel, mas, no caso do GET, normalmente voc\u00ea obter\u00e1 um SUCCESS se o documento existir ou um NOT_FOUND se o documento n\u00e3o existir. Portanto, uma coisa que podemos fazer \u00e9 o seguinte:<\/p>\n

    Ao alterar o c\u00f3digo e executar o JFR novamente, as aloca\u00e7\u00f5es de matriz desapareceram:<\/p>\n

    <\/p>\n

    Na maioria das vezes, os desenvolvedores tendem a parar nesse ponto, mas eu recomendo que voc\u00ea continue lendo. O fato de termos evitado as aloca\u00e7\u00f5es de array (o que \u00e9 bom) n\u00e3o significa que seja mais r\u00e1pido, certo? Em geral, acredita-se que sim, mas j\u00e1 fui surpreendido muitas vezes no passado para acreditar nisso. Mesmo que estejamos certos, \u00e9 bom fazer um microbenchmark r\u00e1pido do JMH para descobrir isso. Isso tamb\u00e9m nos permitir\u00e1 quantificar quaisquer melhorias para o N\u00b01 acima, e n\u00e3o apenas para o N\u00b03, que j\u00e1 verificamos.<\/p>\n

    O JMH faz parte do projeto OpenJDK e n\u00e3o \u00e9 muito dif\u00edcil de usar. Voc\u00ea pode configurar um projeto usando o comando mvn archetype:generate que pode ser encontrado em sua p\u00e1gina inicial. Depois de ter o esqueleto do projeto, voc\u00ea tem duas op\u00e7\u00f5es: adicionar o Java SDK como uma depend\u00eancia (ele ser\u00e1 sombreado automaticamente) ou simplesmente copiar o enum. Dependendo do tamanho de seus testes e do que deseja testar, voc\u00ea deve escolher uma das duas op\u00e7\u00f5es. Como nossos testes atuais s\u00e3o independentes, podemos copiar o ENUM para o projeto. Isso tem a vantagem de podermos modific\u00e1-lo \u00e0 medida que avan\u00e7amos, adicionar novos m\u00e9todos para testar coisas e coisas do g\u00eanero.<\/p>\n

    Copiei a classe KeyValueStatus da vers\u00e3o 2.2.0 e alterei o c\u00f3digo para que possamos chamar duas variantes ao mesmo tempo:<\/p>\n

    Agora podemos escrever nosso benchmark JMH (simples):<\/p>\n

    Em seguida, compilamos o c\u00f3digo e o executamos na linha de comando. Primeiro, execute \"mvn clean install\" e, em seguida, inicie-o com \"java -jar target\/benchmarks.jar -wi 10 -f1 -i 10 -bm avgt -tu ns\".<\/p>\n

    Se isso for muito complicado para voc\u00ea, significa apenas que queremos medir a lat\u00eancia m\u00e9dia em nanossegundos e realizar 10 itera\u00e7\u00f5es de aquecimento, bem como 10 itera\u00e7\u00f5es medidas em uma bifurca\u00e7\u00e3o. Curioso? Aqui est\u00e3o os resultados:<\/p>\n

    Todas as opera\u00e7\u00f5es est\u00e3o no intervalo inferior de nanossegundos, portanto, a JVM faz um bom trabalho de otimiza\u00e7\u00e3o do loop, mas n\u00e3o consegue superar as opera\u00e7\u00f5es simples de compara\u00e7\u00e3o e retorno. Como o c\u00f3digo otimizado tem um fallback, voc\u00ea pode ver no c\u00f3digo 134 que ele retorna ao loop. O que voc\u00ea pode ver al\u00e9m disso nas execu\u00e7\u00f5es \"originais\" \u00e9 que tamb\u00e9m importa onde os elementos s\u00e3o colocados no ENUM depois que voc\u00ea faz o loop sobre ele. 0 e 1 est\u00e3o praticamente na parte superior, enquanto 134 est\u00e1 na parte inferior. Portanto, at\u00e9 mesmo a reordena\u00e7\u00e3o para o caso comum faz sentido.<\/p>\n

    Portanto, a esta altura, estamos bastante convencidos de que faz sentido implementar essa altera\u00e7\u00e3o. Ela reduz as aloca\u00e7\u00f5es e \u00e9 mais r\u00e1pida de executar. Al\u00e9m disso, ela n\u00e3o torna o c\u00f3digo muito mais complexo. Na pr\u00e1tica, por\u00e9m, precisamos de mais c\u00f3digos no caminho otimizado, j\u00e1 que esses dois n\u00e3o s\u00e3o suficientes. Da longa lista enum, eles s\u00e3o:<\/p>\n