El objetivo de las pruebas de carga deber\u00eda ser identificar qu\u00e9 carga puede soportar su cl\u00faster actual y c\u00f3mo necesita mutar y adaptar la configuraci\u00f3n de su cl\u00faster a medida que alcanza diversos hitos de carga. El resultado deber\u00eda ser un plan sobre c\u00f3mo adaptar su cl\u00faster para gestionar el crecimiento y la carga de usuarios antes de que necesite esta informaci\u00f3n. Esto le permite el lujo de planificar con antelaci\u00f3n, manteniendo sus aplicaciones y bases de datos funcionando con los SLA deseados, sin ca\u00eddas en el servicio a medida que su carga crece m\u00e1s all\u00e1 de la capacidad de su configuraci\u00f3n actual.<\/p>\n
Comprenda que no es una informaci\u00f3n que nadie le vaya a proporcionar sin realizar un n\u00famero significativo de pruebas. Hay muchas variables a tener en cuenta, como los patrones de acceso, las estructuras de datos, el c\u00f3digo de la aplicaci\u00f3n, la red, el hardware, etc. Esto se aplica no s\u00f3lo en un centro de datos autoalojado, sino tambi\u00e9n en entornos alojados en la nube. No hay nada mejor que realizar estas pruebas de carga preventivas para su caso de uso espec\u00edfico.<\/p>\n
Nota:<\/strong> Si alojas tu cl\u00faster de Couchbase en un entorno en la nube (AWS, Azure, Google Cloud, etc.), agilizar\u00e1s el proceso de creaci\u00f3n de varias configuraciones de cl\u00faster de Couchbase aprovechando Couchbase Kubernetes Autonomous Operator. Esta herramienta te permite realizar cambios en la configuraci\u00f3n del cl\u00faster en el archivo yaml de Kubernetes, y luego los cambios en el cl\u00faster se despliegan autom\u00e1ticamente. Elimina una gran cantidad de trabajo administrativo del sistema instalando y configurando Couchbase en nodos, a\u00f1adiendo y eliminando nodos de un cl\u00faster, realizando reequilibrios, etc.<\/em><\/p>\n Antes de realizar cualquier prueba de rendimiento, debe tener articulados sus ANS (Acuerdos de Nivel de Servicio). \"Lo m\u00e1s r\u00e1pido posible\" no es un SLA. Es necesario especificar el SLA para que el rendimiento de las pruebas se convierta en una situaci\u00f3n de aprobado o suspenso. O bien el cl\u00faster tiene un rendimiento igual o superior a lo que se ha determinado que necesita, o bien no lo tiene. Si no ha determinado cu\u00e1l es ese tiempo de respuesta, nunca ser\u00e1 capaz de determinar a qu\u00e9 carga el rendimiento ha entrado en el rango inaceptable y necesita ser escalado para volver a rendir al nivel que necesita.<\/p>\n \u00bfC\u00f3mo determinar cu\u00e1l debe ser su SLA? Empiece por el proceso m\u00e1s complejo que deba completarse en un plazo limitado. A menudo se tratar\u00e1 de una interacci\u00f3n con el usuario que no quiere que espere m\u00e1s de X segundos para completarse. Ocasionalmente ser\u00e1 un proceso de microservicio que necesita ser lo m\u00e1s en tiempo real posible. En resumen, tiene que ser alg\u00fan proceso que tenga un punto de inicio y final definido, y una ventana de tiempo espec\u00edfica en la que debe completarse.<\/p>\n Una vez que tenga su proceso, tendr\u00e1 que identificar el n\u00famero de interacciones con la base de datos que se realizan durante este proceso, junto con la naturaleza de cada una de estas interacciones. Una vez identificadas, tendr\u00e1s que eliminar las interacciones con la base de datos para obtener unos tiempos base del proceso. Aqu\u00ed es donde entran en juego los objetos simulados. Utilice objetos simulados para sustituir las interacciones con la base de datos, devolviendo inmediatamente un conjunto realista de resultados de interacci\u00f3n con la base de datos sin la interacci\u00f3n real con la base de datos. Al poner su proceso bajo carga sin las interacciones con la base de datos, puede determinar cu\u00e1nto tiempo el proceso interactivo sin base de datos elimina del tiempo total permitido para el proceso completo. El tiempo restante es la ventana dentro de la cual deben realizarse todas las interacciones con la base de datos.<\/p>\n Nota:<\/strong> Una vez que sepa cu\u00e1nto tiempo hay disponible para las interacciones con la base de datos, debe dar un paso atr\u00e1s y determinar si su l\u00f3gica de negocio est\u00e1 dejando tiempo suficiente para las interacciones con la base de datos. Si la l\u00f3gica de negocio est\u00e1 empleando todo el tiempo permitido para cumplir los SLA, es posible que sus SLA no sean realistas y deban revisarse. Si su l\u00f3gica de negocio no deja tiempo suficiente para las interacciones con la base de datos, debe aumentar sus SLA, racionalizar su l\u00f3gica de negocio o reducir el n\u00famero de interacciones con la base de datos que deben realizarse.<\/em><\/p>\n Una vez que se tiene el n\u00famero de interacciones con la base de datos y el tiempo en el que deben realizarse, es cuesti\u00f3n de hacer algunos c\u00e1lculos para determinar el tiempo en el que cada interacci\u00f3n con la base de datos debe devolver resultados. A partir de aqu\u00ed, hay que determinar la combinaci\u00f3n de interacciones con la base de datos. \u00bfSon todas accesos K\/V? \u00bfSon todas consultas N1QL? \u00bfUna mezcla de ambas? En cuanto a sus consultas N1QL, \u00bfson todas consultas simples, o hay algunas consultas complejas mezcladas? Es a partir de la mezcla de interacciones que puede crear una mezcla escalada de SLA de base de datos, donde sus accesos K\/V tienen un SLA, sus consultas simples N1QL tienen otro, y sus consultas complejas tienen un tercero. Tenga en cuenta que estos ser\u00e1n los SLA objetivos medios para sus interacciones con la base de datos. No todas las interacciones cumplir\u00e1n un SLA espec\u00edfico, pero la media deber\u00eda cumplirlo o superarlo.<\/p>\n Una vez definidos los acuerdos de nivel de servicio, hay que determinar el nivel de degradaci\u00f3n del rendimiento aceptable. A medida que aumenta la carga en el cl\u00faster, llega un punto en el que el rendimiento de la aplicaci\u00f3n y de la base de datos empieza a degradarse. Es necesario determinar cu\u00e1nto de esta degradaci\u00f3n es aceptable. Este n\u00famero te proporciona la l\u00ednea en la arena m\u00e1s all\u00e1 de la cual no puedes permitir que tu rendimiento se degrade m\u00e1s. Este ser\u00e1 el punto de ruptura en la carga que tu cluster puede manejar. Esto se utilizar\u00e1 como un moj\u00f3n de carga para determinar cu\u00e1ndo su cl\u00faster necesita ser reconfigurado para manejar m\u00e1s carga para evitar una mayor degradaci\u00f3n. Recuerde que el objetivo de estas pruebas es producir una hoja de ruta para la configuraci\u00f3n de su cl\u00faster, para que sepa cu\u00e1nta carga puede manejar cada configuraci\u00f3n de cl\u00faster, y determinar los hitos que se\u00f1alar\u00e1n que es hora de reconfigurar su cl\u00faster para manejar aumentos en la carga.<\/p>\n Ahora que tienes tu SLA objetivo para el proceso completo, y tienes un tiempo medio de rendimiento conocido para las interacciones no relacionadas con la base de datos, y has calculado cu\u00e1les deber\u00edan ser tus interacciones con la base de datos, necesitas determinar si tu configuraci\u00f3n actual del cluster de Couchbase puede cumplir estos SLAs.<\/p>\n En primer lugar, bajo una herramienta gen\u00e9rica de generaci\u00f3n de carga como pillowfight o n1qlback, \u00bfcumple tu cluster los SLAs de tiempo de respuesta necesarios, o necesitas aumentar tus SLAs para proporcionar una ventana de procesamiento mayor? Asumiendo que tus SLAs son te\u00f3ricamente alcanzables, la siguiente pregunta es si tu aplicaci\u00f3n actual y la configuraci\u00f3n del cluster de Couchbase pueden cumplir tus SLAs. Una vez que hayas verificado que los SLAs deseados son alcanzables por tu proceso de negocio full-stack, tanto la aplicaci\u00f3n como el cluster de base de datos, ahora es el momento de aumentar la carga para ver c\u00f3mo escala todo.<\/p>\n Una vez que haya confirmado que sus SLA son alcanzables con su configuraci\u00f3n actual, podr\u00eda aumentar inmediatamente la carga a su carga objetivo de usuario\/proceso y ver c\u00f3mo se comporta, pero eso podr\u00eda no ser una buena idea. Si aumentas la carga de forma significativa y de repente descubres que ya no cumples tus SLA, no habr\u00e1s obtenido ninguna informaci\u00f3n \u00fatil. Puede que sepa que su cl\u00faster necesitar\u00e1 escalar antes de que se alcance ese nivel de carga, pero no sabe cu\u00e1ndo debe escalar. En resumen, a\u00fan no dispone de informaci\u00f3n procesable.<\/p>\n Lo que quieres hacer es a\u00f1adir carga gradualmente mientras observas el tiempo de respuesta para determinar cu\u00e1ndo el rendimiento de la configuraci\u00f3n actual se degrada m\u00e1s all\u00e1 de los SLA deseados, tomando nota de cu\u00e1ndo se cruza este umbral. Tambi\u00e9n querr\u00e1 seguir aumentando la carga hasta que el rendimiento se degrade hasta el punto en que se cruce el segundo SLA degradado. Esto tambi\u00e9n necesita ser anotado para que tenga los dos mojones de carga, marcando cu\u00e1ndo necesita escalar su cluster, y qu\u00e9 carga necesita haber completado su escalado de cluster antes de alcanzar.<\/p>\n Una vez que hayas identificado la carga que degrada el rendimiento de tu cluster hasta un grado inaceptable, la siguiente pregunta que tienes que responder es qu\u00e9 servicio de Couchbase no puede manejar la carga. \u00bfEs el acceso K\/V el que est\u00e1 sufriendo? \u00bfConsultas N1QL? \u00bfTiene el servicio de \u00edndices una gran cola de actualizaciones pendientes que no parece aguantar? \u00bfAlguno de los nodos muestra una carga de CPU cercana a 100%? Estas son algunas pistas a tener en cuenta para determinar c\u00f3mo escalar tu cluster de Couchbase.<\/p>\n Una vez que hayas a\u00f1adido uno o dos nodos al servicio concreto que hayas determinado que es el que sufre la carga, repite el proceso de escalado de carga hasta que vuelvas a encontrar la carga que degrada el rendimiento. \u00bfHa cambiado algo al a\u00f1adir el nodo? Si no es as\u00ed, es posible que haya identificado el servicio equivocado para escalar. Si marc\u00f3 la diferencia, y su cl\u00faster puede soportar una carga mayor, entonces tiene un par de hitos m\u00e1s para escalar.<\/p>\n Una vez m\u00e1s, repite el mismo an\u00e1lisis que antes para determinar qu\u00e9 servicio escalar esta vez. Tal vez sea el mismo que antes, tal vez sea un servicio diferente. La clave es asegurarse de que cada vez que a\u00f1ada nodos a su cl\u00faster para gestionar un aumento de la carga, est\u00e9 seguro de que los est\u00e1 a\u00f1adiendo al servicio que necesita ser escalado.<\/p>\n Nota:<\/strong> Si el servicio que se est\u00e1 escalando es el servicio de \u00edndices, recuerde que a\u00f1adir un nodo y ejecutar un reequilibrio no realiza todos los cambios de configuraci\u00f3n necesarios. Para mover \u00edndices de un nodo a otro durante un reequilibrio, el nodo en el que se encuentran los \u00edndices antes del reequilibrio debe marcarse para su eliminaci\u00f3n. De lo contrario, los \u00edndices no se mover\u00e1n. Si solo desea a\u00f1adir uno o dos nodos m\u00e1s a un cl\u00faster en ejecuci\u00f3n mediante Kubernetes, es posible que tenga que mover manualmente \u00edndices individuales de los nodos existentes al nuevo nodo para distribuir la carga.<\/em><\/p>\n Saber qu\u00e9 carga degrada el rendimiento de su configuraci\u00f3n de cl\u00faster no es informaci\u00f3n suficiente para planificar el inicio del escalado. Tambi\u00e9n necesitas saber cu\u00e1ndo es mejor cambiar la configuraci\u00f3n de tu cluster. Escalar tu cluster Couchbase no es s\u00f3lo cuesti\u00f3n de a\u00f1adir un nodo y encenderlo. El cluster requerir\u00e1 que se ejecute un rebalanceo antes de que el nuevo nodo comience a tomar cualquier carga como parte del cluster. \u00bfC\u00f3mo afectar\u00e1 el reequilibrio a sus SLA? \u00bfQu\u00e9 carga puede seguir ejecutando simult\u00e1neamente con un reequilibrio y seguir cumpliendo sus SLA?<\/p>\n La \u00fanica forma de responder a estas preguntas es adoptar el mismo enfoque, comenzando con una carga muy ligera y aumentando gradualmente la carga simult\u00e1neamente con un reequilibrio de adici\u00f3n de nodos en ejecuci\u00f3n. Una vez que haya identificado una carga aceptable mientras ejecuta un reequilibrio, puede observar sus patrones de uso para identificar un d\u00eda y una hora en los que es preferible ejecutar cualquier reequilibrio que cambie la configuraci\u00f3n.<\/p>\n Una vez que disponga de las distintas m\u00e9tricas de capacidad de carga, tanto con procesos operativos como sin ellos, podr\u00e1 elaborar su plan para anticiparse y adaptarse al crecimiento. Su plan debe incluir activadores de hitos para identificar cu\u00e1ndo escalar su cl\u00faster, c\u00f3mo escalarlo y cu\u00e1ndo programar el escalado.<\/p>\n El plan de crecimiento resultante deber\u00eda especificar alguna m\u00e9trica que actuar\u00e1 como disparador para cada evento de escalado, y qu\u00e9 deber\u00eda hacerse como parte del escalado (por ejemplo, a\u00f1adir 1 nodo K\/V, 2 nodos de consulta). Cuando se alcancen estos desencadenantes en su entorno de producci\u00f3n, programe los cambios apropiados en su cl\u00faster, implement\u00e1ndolos en la primera ventana apropiada (momento de baja carga). Si la carga de su cl\u00faster es estacional, estas subidas y bajadas de escala pueden y deben planificarse con mucha antelaci\u00f3n.<\/p>\n Si los cambios en la carga no son estacionales, sino el resultado de un crecimiento org\u00e1nico, su mapa de hitos deber\u00eda incluir marcadores adicionales alrededor de la marca 80% del siguiente hito de cambio de cluster. Estos marcadores 80% deben considerarse hitos de \"prep\u00e1rate\", alertando a tu equipo de que la carga de tu cluster est\u00e1 creciendo y que necesitas planificar el escalado de tu cluster pronto, haciendo los preparativos necesarios.<\/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>\n","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"],"yoast_head":"\nEspecifique sus ANS<\/h2>\n
Encontrar el punto de ruptura de la configuraci\u00f3n actual<\/h2>\n
Pruebas con m\u00faltiples configuraciones de crecimiento<\/h2>\n
Operaciones de prueba bajo carga<\/h2>\n
Identificar m\u00faltiples configuraciones de objetivos de crecimiento<\/h2>\n