O objetivo do teste de carga deve ser identificar a carga que o seu cluster atual pode suportar e como voc\u00ea precisa alterar e adaptar a configura\u00e7\u00e3o do cluster \u00e0 medida que atinge v\u00e1rios marcos de carga. O resultado deve ser um plano de como adaptar o cluster para lidar com o crescimento e a carga dos usu\u00e1rios antes que voc\u00ea precise dessas informa\u00e7\u00f5es. Isso permite que voc\u00ea se d\u00ea ao luxo de planejar com anteced\u00eancia, mantendo o desempenho dos seus aplicativos e bancos de dados com os SLAs desejados, sem quedas no servi\u00e7o \u00e0 medida que a carga cresce al\u00e9m da capacidade da sua configura\u00e7\u00e3o atual.<\/p>\n
Entenda que essa n\u00e3o \u00e9 uma informa\u00e7\u00e3o que algu\u00e9m vai lhe fornecer sem realizar um n\u00famero significativo de testes. H\u00e1 muitas vari\u00e1veis a serem consideradas, como padr\u00f5es de acesso, estruturas de dados, c\u00f3digo de aplicativo, rede, hardware etc. Isso se aplica n\u00e3o apenas em um data center auto-hospedado, mas tamb\u00e9m em ambientes hospedados na nuvem. N\u00e3o h\u00e1 substituto para a realiza\u00e7\u00e3o desse teste de carga preventivo para seu caso de uso espec\u00edfico.<\/p>\n
Observa\u00e7\u00e3o:<\/strong> Se estiver hospedando seu cluster do Couchbase em um ambiente de nuvem (AWS, Azure, Google Cloud, etc.), voc\u00ea simplificar\u00e1 o processo de cria\u00e7\u00e3o de v\u00e1rias configura\u00e7\u00f5es de cluster do Couchbase aproveitando o Couchbase Kubernetes Autonomous Operator. Essa ferramenta permite que voc\u00ea fa\u00e7a altera\u00e7\u00f5es na configura\u00e7\u00e3o do cluster no arquivo yaml do Kubernetes e, em seguida, as altera\u00e7\u00f5es no cluster s\u00e3o implantadas automaticamente. Isso elimina uma grande quantidade de trabalho administrativo do sistema, instalando e configurando o Couchbase em n\u00f3s, adicionando e removendo n\u00f3s de um cluster, realizando rebalanceamentos e assim por diante.<\/em><\/p>\n Antes de executar qualquer teste de desempenho, voc\u00ea precisa ter seus SLAs (Service Level Agreement) articulados. \"O mais r\u00e1pido poss\u00edvel\" n\u00e3o \u00e9 um SLA. Voc\u00ea precisa ter um SLA especificado para que o desempenho do teste se torne uma situa\u00e7\u00e3o de aprova\u00e7\u00e3o ou reprova\u00e7\u00e3o. Ou o seu cluster est\u00e1 tendo um desempenho igual ou superior ao que voc\u00ea determinou que ele precisa ter, ou n\u00e3o est\u00e1. Se voc\u00ea n\u00e3o tiver determinado qual \u00e9 esse tempo de resposta, nunca conseguir\u00e1 determinar em que carga o desempenho entrou na faixa inaceit\u00e1vel e precisa ser dimensionado para voltar a ter o desempenho no n\u00edvel necess\u00e1rio.<\/p>\n Ent\u00e3o, como voc\u00ea determina qual deve ser o seu SLA? Comece com seu processo mais complexo que precisa ser conclu\u00eddo em um per\u00edodo limitado. Geralmente, trata-se de uma intera\u00e7\u00e3o com o usu\u00e1rio que n\u00e3o deve esperar mais de X segundos para ser conclu\u00edda. Ocasionalmente, ser\u00e1 um processo de microsservi\u00e7o que precisa ser o mais em tempo real poss\u00edvel. Em resumo, deve ser um processo que tenha um ponto inicial e final definido e uma janela de tempo espec\u00edfica na qual ele precisa ser conclu\u00eddo.<\/p>\n Depois de ter seu processo, voc\u00ea precisa identificar o n\u00famero de intera\u00e7\u00f5es com o banco de dados que s\u00e3o realizadas durante esse processo, juntamente com a natureza de cada uma dessas intera\u00e7\u00f5es. Uma vez identificadas, voc\u00ea precisar\u00e1 remover as intera\u00e7\u00f5es com o banco de dados para obter alguns tempos de processo de linha de base. \u00c9 nesse ponto que os objetos de simula\u00e7\u00e3o precisam entrar em a\u00e7\u00e3o. Use objetos simulados para substituir as intera\u00e7\u00f5es com o banco de dados, retornando imediatamente um conjunto realista de resultados de intera\u00e7\u00e3o com o banco de dados sem a intera\u00e7\u00e3o real com o banco de dados. Ao colocar o processo sob carga sem as intera\u00e7\u00f5es com o banco de dados, voc\u00ea pode determinar quanto tempo o processo interativo sem banco de dados remove do tempo total permitido para o processo completo. O tempo restante \u00e9 a janela na qual todas as intera\u00e7\u00f5es com o banco de dados precisam ser executadas.<\/p>\n Observa\u00e7\u00e3o:<\/strong> Depois de saber quanto tempo est\u00e1 dispon\u00edvel para as intera\u00e7\u00f5es com o banco de dados, \u00e9 preciso dar um passo atr\u00e1s e determinar se a l\u00f3gica comercial est\u00e1 permitindo tempo suficiente para as intera\u00e7\u00f5es com o banco de dados. Se a l\u00f3gica de neg\u00f3cios estiver consumindo todo o tempo permitido para atender aos SLAs, ent\u00e3o seus SLAs podem n\u00e3o ser realistas e precisam ser revisados. Se a sua l\u00f3gica de neg\u00f3cios n\u00e3o permitir tempo suficiente para as intera\u00e7\u00f5es com o banco de dados, ser\u00e1 necess\u00e1rio aumentar os SLAs, simplificar a l\u00f3gica de neg\u00f3cios ou reduzir o n\u00famero de intera\u00e7\u00f5es com o banco de dados a serem realizadas.<\/em><\/p>\n Uma vez que voc\u00ea tenha o n\u00famero de intera\u00e7\u00f5es com o banco de dados e o tempo em que elas precisam ser realizadas, \u00e9 simples fazer alguns c\u00e1lculos para determinar o tempo em que cada intera\u00e7\u00e3o com o banco de dados deve retornar resultados. A partir da\u00ed, voc\u00ea deve determinar qual \u00e9 a combina\u00e7\u00e3o das intera\u00e7\u00f5es com o banco de dados. Todas elas s\u00e3o de acesso K\/V? S\u00e3o todas consultas N1QL? Uma combina\u00e7\u00e3o de ambos? Quanto \u00e0s suas consultas N1QL, s\u00e3o todas simples ou h\u00e1 algumas consultas complexas misturadas? \u00c9 a partir da an\u00e1lise da combina\u00e7\u00e3o de intera\u00e7\u00f5es que voc\u00ea pode criar uma combina\u00e7\u00e3o escalonada de SLA de banco de dados, em que seus acessos K\/V t\u00eam um SLA, suas consultas N1QL simples t\u00eam outro e suas consultas complexas t\u00eam um terceiro. Entenda que esses ser\u00e3o os SLAs de destino m\u00e9dio para suas intera\u00e7\u00f5es com o banco de dados. Nem toda intera\u00e7\u00e3o atender\u00e1 a um SLA espec\u00edfico, mas a m\u00e9dia deve atender ou exceder a m\u00e9dia.<\/p>\n Depois de definir os SLAs de destino, voc\u00ea precisa determinar o n\u00edvel de degrada\u00e7\u00e3o de desempenho aceit\u00e1vel. \u00c0 medida que a carga aumenta em seu cluster, h\u00e1 um ponto em que o desempenho do aplicativo e do banco de dados come\u00e7a a se degradar. Voc\u00ea precisa determinar o quanto dessa degrada\u00e7\u00e3o \u00e9 aceit\u00e1vel. Esse n\u00famero fornece a linha na areia al\u00e9m da qual voc\u00ea n\u00e3o pode permitir que o desempenho se degrade ainda mais. Esse ser\u00e1 o ponto de ruptura da carga que seu cluster pode suportar. Ele ser\u00e1 usado como um ponto de refer\u00eancia de carga para determinar quando o cluster precisar\u00e1 ser reconfigurado para lidar com mais carga a fim de evitar mais degrada\u00e7\u00e3o. Lembre-se de que o objetivo desse teste \u00e9 produzir um roteiro para a configura\u00e7\u00e3o do cluster, de modo que voc\u00ea saiba quanta carga cada configura\u00e7\u00e3o de cluster pode suportar e determinar os marcadores de milha que sinalizar\u00e3o que \u00e9 hora de reconfigurar o cluster para lidar com aumentos de carga.<\/p>\n Agora que voc\u00ea tem seu SLA de meta para o processo completo, tem um tempo m\u00e9dio de desempenho conhecido para a intera\u00e7\u00e3o n\u00e3o relacionada ao banco de dados e calculou quais devem ser as intera\u00e7\u00f5es com o banco de dados, \u00e9 necess\u00e1rio determinar se a configura\u00e7\u00e3o atual do cluster do Couchbase pode atender a esses SLAs.<\/p>\n Em primeiro lugar, com uma ferramenta gen\u00e9rica de gera\u00e7\u00e3o de carga, como pillowfight ou n1qlback, seu cluster atende aos SLAs de tempo de resposta necess\u00e1rios ou voc\u00ea precisa aumentar seus SLAs para fornecer uma janela de processamento maior? Supondo que seus SLAs sejam teoricamente alcan\u00e7\u00e1veis, a pr\u00f3xima pergunta \u00e9 se seu aplicativo atual e a configura\u00e7\u00e3o do cluster do Couchbase podem atender aos SLAs. Depois de verificar se os SLAs desejados podem ser atingidos pelo seu processo de neg\u00f3cios de pilha completa, pelo aplicativo e pelo cluster de banco de dados, agora \u00e9 hora de aumentar a carga para ver como tudo \u00e9 dimensionado.<\/p>\n Depois de confirmar que os SLAs podem ser alcan\u00e7ados com a configura\u00e7\u00e3o atual, voc\u00ea pode aumentar imediatamente a carga para a carga de usu\u00e1rio\/processo desejada e ver o desempenho, mas isso pode n\u00e3o ser uma boa ideia. Se voc\u00ea aumentar significativamente a carga de repente e descobrir que n\u00e3o est\u00e1 mais cumprindo os SLAs, n\u00e3o ter\u00e1 obtido nenhuma informa\u00e7\u00e3o \u00fatil. Talvez voc\u00ea saiba que seu cluster precisar\u00e1 ser dimensionado antes que esse n\u00edvel de carga seja atingido, mas n\u00e3o sabe quando dever\u00e1 ser dimensionado. Em resumo, voc\u00ea ainda n\u00e3o tem informa\u00e7\u00f5es acion\u00e1veis.<\/p>\n O que voc\u00ea deseja fazer \u00e9 aumentar gradualmente a carga enquanto observa o tempo de resposta para determinar quando o desempenho da configura\u00e7\u00e3o atual se degrada al\u00e9m dos SLAs desejados, anotando quando esse limite \u00e9 ultrapassado. Voc\u00ea tamb\u00e9m deseja continuar aumentando a carga at\u00e9 que o desempenho se degrade at\u00e9 o ponto em que os segundos SLAs degradados sejam ultrapassados. Isso tamb\u00e9m precisa ser anotado para que voc\u00ea tenha os dois pontos de refer\u00eancia de carga, marcando quando voc\u00ea precisa escalonar o cluster e qual carga voc\u00ea precisa ter conclu\u00eddo o escalonamento do cluster antes de alcan\u00e7\u00e1-la.<\/p>\n Depois de identificar a carga que degrada o desempenho do seu cluster em um grau inaceit\u00e1vel, a pr\u00f3xima pergunta que voc\u00ea precisa responder \u00e9 qual servi\u00e7o do Couchbase n\u00e3o consegue lidar com a carga. \u00c9 o acesso K\/V que est\u00e1 sofrendo? Consultas N1QL? O servi\u00e7o de \u00edndice tem uma grande fila de atualiza\u00e7\u00f5es pendentes que parece n\u00e3o estar conseguindo acompanhar? Algum dos n\u00f3s est\u00e1 mostrando uma carga de CPU pr\u00f3xima a 100%? Essas s\u00e3o algumas pistas a serem observadas para determinar como dimensionar seu cluster do Couchbase.<\/p>\n Depois de adicionar um ou dois n\u00f3s ao servi\u00e7o espec\u00edfico que voc\u00ea determinou ser o que est\u00e1 sofrendo com a carga, repita o processo de aumento de carga at\u00e9 encontrar novamente a carga que degrada o desempenho. A adi\u00e7\u00e3o do n\u00f3 fez alguma diferen\u00e7a? Se n\u00e3o, ent\u00e3o voc\u00ea pode ter identificado o servi\u00e7o errado para escalonar. Se fez diferen\u00e7a, e seu cluster pode lidar com uma carga maior, ent\u00e3o voc\u00ea tem mais alguns marcadores de ponto de milha para dimensionamento.<\/p>\n Novamente, voc\u00ea repete a mesma an\u00e1lise de antes para determinar qual servi\u00e7o deve ser dimensionado desta vez. Talvez seja o mesmo de antes, talvez seja um servi\u00e7o diferente. O segredo \u00e9 garantir que, toda vez que voc\u00ea adicionar n\u00f3s ao cluster para lidar com uma carga maior, tenha certeza de que os est\u00e1 adicionando ao servi\u00e7o que precisa ser dimensionado.<\/p>\n Observa\u00e7\u00e3o:<\/strong> Se o servi\u00e7o que est\u00e1 sendo dimensionado for o servi\u00e7o de \u00edndice, lembre-se de que adicionar um n\u00f3 e executar um rebalanceamento n\u00e3o faz todas as altera\u00e7\u00f5es de configura\u00e7\u00e3o necess\u00e1rias. Para mover os \u00edndices de um n\u00f3 para outro durante um rebalanceamento, o n\u00f3 em que os \u00edndices est\u00e3o antes do rebalanceamento precisa ser marcado para exclus\u00e3o. Caso contr\u00e1rio, os \u00edndices n\u00e3o ser\u00e3o movidos. Se voc\u00ea quiser apenas adicionar mais um ou dois n\u00f3s a um cluster em execu\u00e7\u00e3o usando o Kubernetes, talvez seja necess\u00e1rio mover manualmente os \u00edndices individuais dos n\u00f3s existentes para o novo n\u00f3 para distribuir a carga.<\/em><\/p>\n Saber qual carga degrada o desempenho da sua configura\u00e7\u00e3o de cluster n\u00e3o \u00e9 informa\u00e7\u00e3o suficiente para planejar o in\u00edcio do dimensionamento. Voc\u00ea tamb\u00e9m precisa saber qual \u00e9 o melhor momento para alterar a configura\u00e7\u00e3o do cluster. O dimensionamento do cluster do Couchbase n\u00e3o \u00e9 apenas uma quest\u00e3o de adicionar um n\u00f3 e lig\u00e1-lo. O cluster exigir\u00e1 que um rebalanceamento seja executado antes que o novo n\u00f3 comece a receber qualquer carga como parte do cluster. Como o rebalanceamento afetar\u00e1 seus SLAs? Que carga voc\u00ea pode continuar a executar simultaneamente com um rebalanceamento e continuar a cumprir seus SLAs?<\/p>\n A \u00fanica maneira de responder a essas perguntas \u00e9 adotar a mesma abordagem, come\u00e7ando com uma carga muito leve e aumentando gradualmente a carga simultaneamente \u00e0 execu\u00e7\u00e3o de um rebalanceamento de adi\u00e7\u00e3o de n\u00f3s. Depois de identificar uma carga aceit\u00e1vel para a execu\u00e7\u00e3o de um rebalanceamento, voc\u00ea pode analisar seus padr\u00f5es de uso para identificar um dia e uma hora em que seja prefer\u00edvel executar qualquer rebalanceamento que altere a configura\u00e7\u00e3o.<\/p>\n Depois de obter as v\u00e1rias m\u00e9tricas de capacidade de carga, com e sem processos operacionais, voc\u00ea poder\u00e1 criar um plano para antecipar e adaptar-se ao crescimento. Seu plano deve incluir gatilhos para identificar quando escalonar o cluster, como escalon\u00e1-lo e quando programar o escalonamento.<\/p>\n O plano de crescimento resultante deve especificar alguma m\u00e9trica que atuar\u00e1 como um acionador para cada evento de aumento de escala e o que deve ser feito como parte do aumento de escala (por exemplo, adicionar 1 n\u00f3 K\/V, 2 n\u00f3s de consulta). Quando esses acionadores de milepost forem atingidos em seu ambiente de produ\u00e7\u00e3o, programe as altera\u00e7\u00f5es apropriadas em seu cluster, implementando-as na janela apropriada mais pr\u00f3xima (tempo de baixa carga). Se a carga do cluster for sazonal, esses aumentos e redu\u00e7\u00f5es de escala podem e devem ser planejados com bastante anteced\u00eancia.<\/p>\n Se as mudan\u00e7as na carga n\u00e3o forem sazonais, mas resultarem de crescimento org\u00e2nico, seu mapa de postos de controle deve incluir marcadores adicionais em torno da marca 80% do pr\u00f3ximo posto de controle de mudan\u00e7a de cluster. Esses marcadores 80% devem ser considerados como marcos de milha \"prepare-se\", alertando a sua equipe de que a carga no seu cluster est\u00e1 crescendo e que voc\u00ea precisa planejar o dimensionamento do cluster em breve, tomando as provid\u00eancias preparat\u00f3rias necess\u00e1rias.<\/p>\n <\/p>","protected":false},"excerpt":{"rendered":" The goal of load testing should be to identify what load your current cluster can handle, and how you need to mutate and adapt your cluster configuration as you reach various load milestones. The result should be a plan for […]<\/p>","protected":false},"author":41537,"featured_media":8461,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[1815,1816,2334,2389],"tags":[],"ppma_author":[9086],"class_list":["post-8462","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-best-practices-and-tutorials","category-couchbase-server","category-monitoring","category-solutions"],"acf":[],"yoast_head":"\nEspecifique seus SLAs<\/h2>\n
Localize onde a configura\u00e7\u00e3o atual \u00e9 interrompida<\/h2>\n
Teste com v\u00e1rias configura\u00e7\u00f5es de crescimento<\/h2>\n
Opera\u00e7\u00f5es de teste sob carga<\/h2>\n
Identificar v\u00e1rias configura\u00e7\u00f5es de metas de crescimento<\/h2>\n