Guía de planeamiento de capacidad del almacenamiento en caché de Windows Server AppFabric

Jason Roth, Rama Ramani, Jaime Alva Bravo

Marzo de 2011

En esta nota del producto se proporcionan instrucciones para el planeamiento de capacidad de Almacenamiento en caché de Windows Server AppFabric.

1. Introducción

2. Evaluación del rendimiento del almacenamiento en caché de AppFabric

3. Metodología del planeamiento de capacidad

   1. Primer paso: Comprender los cuellos de botella e identificar los candidatos de almacenamiento en caché

   2. Segundo paso: Evaluar los patrones de la carga de trabajo actual

   3. Tercer paso: Comprender la infraestructura física y los recursos de hardware

   4. Cuarto paso: Finalizar el contrato de nivel de servicio de rendimiento requerido para todas las aplicaciones

   5. Quinto paso: Identificar las características y opciones de configuración adecuadas de AppFabric

4. Herramienta de planeamiento de capacidad

5. Próximos pasos en el planeamiento de capacidad

6. Seguimiento de los requisitos continuos de la capacidad de almacenamiento en caché

Introducción

El almacenamiento en caché de Windows Server AppFabric proporciona un clúster de caché en memoria distribuido. En este documento se proporcionan instrucciones acerca del planeamiento de capacidad para una implementación in situ del almacenamiento en caché de Windows Server AppFabric.

La arquitectura del almacenamiento en caché de Windows Server AppFabric se describe detalladamente en la documentación. Para obtener más información, vea Características de almacenamiento en caché de Windows Server AppFabric. En resumen, un clúster de caché de AppFabric consta de uno o más servidores de caché (también conocidos como hosts de caché). Las memorias caché se distribuyen entre los hosts caché y se almacenan en memoria.

Nota

Tenga en cuenta que también existe una versión de almacenamiento en caché de Windows Azure AppFabric para usar el almacenamiento en caché en la nube. Algunos de los pasos que se describen en este documento en relación con la estimación de los requisitos de memoria se aplicarán a una solución basada en la nube. Sin embargo, este documento se centra específicamente en un escenario de clúster de caché in situ. Para obtener más información acerca del uso de la característica de almacenamiento en caché de Azure AppFabric, vea Almacenamiento en caché de Windows Azure AppFabric.

La información que se incluye en este documento se basa en el trabajo de planeamiento que Microsoft ha llevado a cabo con clientes. Todos los clientes de almacenamiento en caché de AppFabric hacen una pregunta común: “¿Cuántos servidores se necesitan para mi escenario?” En muchas de estas conversaciones, se comienza con la respuesta habitual “Depende”. A continuación, se obtienen detalles sobre los distintos aspectos y, en última instancia, se llega a un buen punto de partida. Durante este proceso, surgen otras preguntas más específicas:

• ¿Cuánta memoria de almacenamiento en caché necesitan mis aplicaciones?

• ¿Cuántos equipos debo usar en cada clúster de caché?

• ¿De cuánta memoria debería disponer cada equipo? ¿Cómo se deben configurar los equipos?

• ¿De qué modo el ancho de banda de la red afecta al rendimiento del clúster de caché?

El objetivo de esta nota del producto es capturar las lecciones aprendidas de este tipo de conversación con los clientes con el fin de proporcionar una metodología que se podrá usar para el planeamiento de capacidad.

Si está leyendo este documento, es posible que se encuentre en una de varias fases de desarrollo:

1. Empieza a analizar el almacenamiento en caché distribuido y no dispone de datos detallados sobre la combinación de cargas de trabajo, los requisitos de rendimiento o la topología de implementación de servidores. Llegado a este punto, puede comenzar con la revisión de algunos de los datos de rendimiento del almacenamiento en caché de AppFabric.

2. O bien, ya ha investigado las características y el rendimiento del almacenamiento en caché de AppFabric. Ahora, quiere ayuda sobre su escenario específico y los requisitos de alto nivel correspondientes. Aquí es donde obtiene los detalles del planeamiento de capacidad.

3. Por último, podría encontrarse ya en la fase de producción. Llegado a este punto, desea comprender cómo analizar los datos de rendimiento para asegurarse de que dispone de capacidad suficiente. Asimismo, también desea planear las ampliaciones futuras de la carga de trabajo, sabiendo que los indicadores clave y las prácticas recomendadas se basan en el comportamiento en tiempo de ejecución de la memoria caché de AppFabric.

Esta nota del producto se ha estructurado para tratar estas fases de manera secuencial. Si simplemente está evaluando el rendimiento de AppFabric, es recomendable consultar la nota del producto redactada por nuestro partner Grid Dynamics. Aquí, los datos de dicha nota del producto se agrupan de modo que facilitan la evaluación e indican el proceso de planeamiento de capacidad.

Si está listo para realizar el proceso de planeamiento de capacidad, se proporciona un conjunto de pasos para formalizar una metodología que podrá aplicar a su escenario concreto.

Si está usando o probando un clúster de caché, podrá validar el proceso de planeamiento de capacidad al analizar un conjunto clave de indicadores de rendimiento para asegurarse de que dispone de la capacidad adecuada. Además, se analizarán algunas prácticas recomendadas.

Evaluación del rendimiento del almacenamiento en caché de AppFabric

Nuestro partner, Grid Dynamics, completó recientemente una serie de pruebas sobre el rendimiento del almacenamiento en caché de AppFabric. Sus resultados se publicaron en la siguiente nota del producto: Windows Server AppFabric Cache: A detailed performance & scalability datasheet.

Cada prueba se centró en una variable específica, tal como el tamaño de la memoria caché o el número de servidores del clúster de caché. El estudio de Grid Dynamics se puede usar para evaluar el rendimiento y la escabilidad del almacenamiento en caché de AppFabric. Es posible comparar las cifras de rendimiento y latencia de una gran variedad de escenarios y topologías de prueba con sus requisitos de aplicación. Normalmente, en cada prueba se variaron solo uno o dos parámetros con el fin de centrarse en el impacto de su rendimiento. El conjunto completo de parámetros incluye lo siguiente:

Patrón de carga	Patrón de uso de caché, por ejemplo, el porcentaje de las operaciones 'Get', 'Put', 'BulkGet', 'GetAndLock' y 'PutAndUnlock
Tamaño de datos almacenados en caché	La cantidad de datos almacenados en caché durante la prueba
Tamaño de clúster	El número de servidores del clúster de caché
Tamaño de objeto	El tamaño de los objetos después de la serialización que se almacenan en caché
Complejidad de tipo	Los distintos tipos de objeto .NET, tal como byte, string[], etc., que se almacenan en caché
Seguridad	La configuración de seguridad del clúster de caché

Además de comprobar el rendimiento y la escabilidad del almacenamiento en caché de AppFabric, Grid Dynamics ha proporcionado el agente de prueba para permitirle repetir las pruebas con sus propios datos y cargas de trabajo. Se trata de otra opción que permite evaluar el rendimiento del almacenamiento en caché de su escenario específico.

Aunque es muy recomendable ver todo el estudio y sus conclusiones, a continuación se incluye un resumen de algunos de los resultados del estudio que proporcionan prácticas recomendadas que se analizan en el resto del documento:

• El almacenamiento en caché de AppFabric realiza una escala lineal a medida que se agregan más equipos a un clúster de caché.

• El tamaño de la memoria caché no tiene un impacto significativo, excepto en cachés con un elevado porcentaje de operaciones de escritura. Entre otros factores, las cargas de trabajo de escritura elevadas afectan a la recolección de elementos .NET no usados cuando el tamaño de la pila administrada es importante.

• Una complejidad de tipo elevada solo afecta al rendimiento del cliente debido a la serialización.

• Las llamadas get masivas tienen como resultado una mejor utilización de la red. El acceso directo a la memoria caché es mucho más rápido que con servidores proxy (ASP.NET, WCF), pero esto se debe al rendimiento de la capa intermedia en lugar del rendimiento del almacenamiento en caché.

• El rendimiento del bloqueo pesimista y optimista es similar, por lo que debería usar la técnica que mejor se adapte al diseño de la aplicación. Tanto la latencia como el rendimiento mejoran cuando disminuye la frecuencia de conflictos.

• La seguridad del clúster de caché no disminuye el rendimiento y está habilitada de manera predeterminada. El rendimiento más alto y la latencia más baja se obtienen cuando la seguridad está desactivada. Sin embargo, esto podría ser inaceptable debido a los requisitos de confidencialidad de datos y empresariales.

• Los cuellos de botella de la red se reducen mediante el uso de una red dedicada entre los servidores de aplicación y los de caché.

Tenga en cuenta que el documento de Grid Dynamics es un buen punto de partida para iniciar una evaluación del almacenamiento en caché de AppFabric y que, además, contiene datos sin formato y patrones observados que se pueden usar para indicar el proceso de planeamiento de capacidad.

Metodología del planeamiento de capacidad

Una vez que haya decidido que la aplicación podría beneficiarse de caché en memoria distribuida, tal como el almacenamiento en caché de AppFabric, pasará a la etapa de planeamiento de capacidad. Aunque es posible realizar algunos pasos en el planeamiento de capacidad a través de pruebas directas contra el clúster de caché de AppFabric, es posible que sea necesario crear una estimación sin este tipo de pruebas. Este es el enfoque de esta sección. Los pasos siguientes proporcionan una manera sistemática de pensar en los requisitos de almacenamiento en caché de AppFabric:

1. Comprender los cuellos de botella e identificar los candidatos de almacenamiento en caché

2. Evaluar los patrones de la carga de trabajo actual

3. Comprender la infraestructura física y los recursos de hardware

4. Finalizar el contrato de nivel de servicio de rendimiento requerido para todas las aplicaciones

5. Identificar las características y opciones de configuración adecuadas de AppFabric

En este documento se proporcionan ejemplos de estos pasos al examinar las necesidades de una aplicación de tienda en línea de ejemplo. Sin embargo, el almacenamiento en caché lo puede usar cualquier tipo de aplicación .NET y es posible tener más de una aplicación que accede al mismo clúster de caché. En este escenario, debería realizar los pasos siguientes para cada aplicación y agregar los resultados para obtener una estimación precisa de la capacidad.

Primer paso: Comprender los cuellos de botella e identificar los candidatos de almacenamiento en caché

En primer lugar, identifique los datos que desee almacenar en caché. Para ello, se pueden usar herramientas de análisis del rendimiento, tal como SQL Server Profiler, Monitor de rendimiento, Prueba de Visual Studio, entre otras. Estas herramientas pueden identificar los objetos de base de datos a los que se acceden con frecuencia o ralentizar las llamadas a los servicios web. Los conjuntos de datos que se devuelven desde estos almacenes back-end son candidatos potenciales para el almacenamiento en caché. El almacenamiento temporal de estos datos en la memoria caché puede mejorar el rendimiento y aliviar la carga en los almacenes de datos back-end.

Una vez que haya identificado los candidatos potenciales de almacenamiento en caché, es un ejercicio útil clasificar dichos objetos en una de tres categorías principales: Datos de actividad, Datos de referencia y Datos de recurso. Estos elementos se explican mejor mediante ejemplos.

• Los Datos de actividad contienen datos de lectura y escritura relacionados con un usuario individual. Por ejemplo, en una tienda en línea, el carro de la compra de un usuario corresponde a los datos de actividad. Se aplica a la sesión actual del usuario y podría cambiar con frecuencia. Aunque es importante mantener una alta disponibilidad para el carro de la compra, se trata de datos que no necesariamente necesitan un almacenamiento permanente en una base de datos back-end. Debido a sus características temporales, los datos de actividad son candidatos lógicos para el almacenamiento en caché.

• Los Datos de referencia son datos de solo lectura que se comparten entre varios usuarios o varias instancias de aplicación. Se accede a ellos con frecuencia, pero estos datos no cambian muy a menudo. Por ejemplo, en el ejemplo de la tienda en línea, el catálogo de productos corresponde a datos de referencia. El catálogo sería válido durante uno o más días, pero distintos usuarios podrían obtener acceso a él miles de veces. Este tipo de datos también son un buen candidato para el almacenamiento en caché. Sin algún tipo de almacenamiento en caché, cada usuario que visualice el catálogo de productos deberá acceder a los datos desde la base de datos. El uso del almacenamiento en caché puede aliviar la carga en la base de datos back-end en relación con solicitudes repetidas de datos semiestáticos. Debido a sus características permanentes, estos datos también son candidatos lógicos para el almacenamiento en caché.

• Los Datos de recurso son datos de escritura y lectura que se comparten entre todos los usuarios. Por ejemplo, un foro de soporte técnico contiene este tipo de datos. Todos los usuarios pueden leer una respuesta a los mensajes del foro.

Debido a que distintos tipos de datos en caché tendrán distintos patrones de uso, la clasificación de datos en estas categorías puede ser de utilidad. Por ejemplo, la identificación de un objeto como datos de referencia sugiere automáticamente que se trata más de una carga de trabajo de solo lectura. También puede ayudar a determinar las directivas de expiración, que suelen ser más cortas para los datos que cambian con mayor frecuencia. Para el desarrollo, estas divisiones lógicas pueden sugerir áreas que se pueden encapsular en el código.

Es recomendable crear estimaciones para objetos individuales que agregar dichos datos. En la tabla siguiente se muestra un ejemplo de la información recolectada en esta fase:

Objeto para almacenar en caché	Categorización del almacenamiento en caché	Ubicación de almacenamiento permanente
Objeto de carro de la compra	Datos de actividad	Ninguno
Objeto de preferencias de usuario	Datos de actividad	Base de datos back-end
Catálogo de productos	Datos de referencia	Base de datos back-end
Hilo de mensajes de foro de usuario	Datos de recursos	Base de datos back-end

Al identificar datos candidatos para el almacenamiento en caché, no es necesario buscar datos para almacenar en caché en cada categoría. Es posible que el rendimiento y la escabilidad mejoren simplemente mediante el almacenamiento en caché del carro de la compra de la aplicación. Lo importante de este paso es usar la información disponible para identificar los mejores elementos para almacenar en caché.

Segundo paso: Evaluar los patrones de la carga de trabajo actual

Cuando haya determinado los datos adecuados para almacenar en caché, debe comprender cómo la aplicación accede a los datos y los patrones de carga de trabajo asociados. Al final de este paso, debería poder llegar a una estimación general de los requisitos de memoria de almacenamiento en caché. También debería comprender mejor cómo se accede a los datos y cómo estos se usan; información importante para los pasos posteriores.

Por ejemplo, si el catálogo de productos es un candidato objetivo para el almacenamiento en caché, debería explorar cuándo la aplicación recupera los datos del catálogo y con qué frecuencia se realizan estas solicitudes. Según el paso anterior, debería saber que se trata de datos de referencia y, por tanto, es una carga de trabajo principalmente de solo lectura. Comprender completamente los patrones de la carga de trabajo para los distintos objetos guiará las decisiones futuras sobre la capacidad. Analicemos más de cerca lo que implica este paso.

Hay varias maneras de comprender mejor los patrones actuales de acceso a datos:

1. Revisar detalladamente el código para ver dónde se obtiene acceso a los datos y la frecuencia de dicho acceso.

2. Usar un generador de perfiles del código que pueda proporcionar la frecuencia de llamadas de método y los datos de rendimiento asociados.

3. Crear instrumentación en el código alrededor de secciones específicas de acceso a datos. Registrar los intentos de acceso a datos y el rendimiento asociado de la operación de datos.

4. Usar un generador de perfiles de base de datos, tal como SQL Server Profiler, para observar el número y la duración de operaciones de base de datos.

Tenga en cuenta que muchas de estas técnicas podrían haberse usado en el paso anterior para determinar los datos objetivo para el almacenamiento en caché. No obstante, durante esta fase el interés es obtener números más detallados que se puedan usar en los cálculos futuros de planeamiento de capacidad.

Parte de esta evaluación implica comprender la frecuencia de lecturas frente a escrituras. La carga de trabajo de lectura y escritura puede influenciar en las decisiones posteriores sobre la capacidad. Por ejemplo, una carga de trabajo con un elevado porcentaje de escrituras desencadenará una mayor recolección de elementos .NET no usados. Esto se trata en un paso posterior.

Otro factor es la frecuencia de lecturas y escrituras que se producen durante la carga pico. En la tabla siguiente se muestran datos de ejemplo recolectados durante esta etapa para el objeto de carro de la compra de ejemplo.

Objeto para analizar	Carro de la compra
% de lecturas	50%
% de escrituras	50%
Operaciones de lectura por segundo (máximo)	250
Operaciones de escritura por segundo (máximo)	250

Nuevamente, este mismo análisis se puede realizar para cada tipo de objeto. Distintos tipos de objeto tendrá diferentes patrones de acceso y diferentes operaciones máximas de lectura y escritura por segundo bajo la carga.

Para comprender los requisitos de almacenamiento en caché, deberá tener una estimación del número máximo de objetos activos de cada tipo en la memoria caché en cualquier momento dado. Esta estimación implica conseguir un equilibrio entre la frecuencia de inserciones de objeto y la duración prevista de dichos objetos. Esto se comprenderá mejor mediante un ejemplo.

En el ejemplo de aplicación web de ASP.NET, los datos operativos pueden mostrar que se producen tiempos picos de 25.000 usuarios simultáneos. Cada usuario requiere información de estado de sesión, por lo que se trata de 25.000 objetos en caché. Sin embargo, la expiración de estos objetos podría establecerse en treinta minutos. Durante los tiempos picos, los datos operativos pueden mostrar que hay 5.000 usuarios nuevos por hora, lo que significa que podrían llegar 2.500 usuarios nuevos durante el período de expiración de treinta minutos. Además, algunos usuarios podrían cerrar su explorador e iniciar una sesión nueva. Aunque se trate del mismo usuario, este ahora usa una sesión diferente. Por consiguiente, debería establecer relleno adicional para ello. Por último, se debería planear para cualquier crecimiento anticipado de los próximos 6 a 12 meses. Al final, el cálculo del número máximo de objetos activos en la memoria caché podría tener el aspecto siguiente:

Objeto para analizar:	Carro de la compra
Usuarios simultáneas en tiempos picos	25.000
Nuevos usuarios durante el período de expiración (30 minutos)	2.500
Usuarios existentes que inician nuevas sesiones de explorador	250
Estimación de crecimiento futuro (25%)	6.940
Total de objetos activos (máximo):	Máximo de 35.000 objetos activos aproximadamente

Si se producen cambios en las entradas, tal como el período de expiración, cambiará el número de objetos sin expirar que residen en caché durante la carga pica. Esto es solo un ejemplo del proceso de análisis. Otros tipos de objeto podrían tener patrones distintos y variables diferentes que se incluyen en el cálculo. Por ejemplo, si un catálogo de productos compartido es válido para un día completo, el número máximo de objetos de catálogo de productos en caché durante el día debería ser uno.

Sin embargo, conocer el número máximo de objetos en caché solo ayuda si también conoce el tamaño de objeto promedio. De manera inherente, este problema presenta dificultades. En el ejemplo del carro de la compra, un usuario podría colocar un único artículo en su carro, mientras que otro podría tener diez o veinte artículos. El objetivo es comprender el promedio. Al igual que la mayoría de los números del proceso, no será perfecto, pero el resultado final es un punto de partida bien analizado para el clúster de caché en lugar de tan solo adivinar.

Los objetos se almacenan en caché de manera serializada. Por consiguiente, para comprender el tamaño de objeto promedio, se debe calcular el tamaño de objeto serializado promedio. AppFabric usa la clase NetDataContractSerializer para la serialización antes de almacenar los elementos en caché. Para determinar el tamaño de objeto promedio, agregue código de instrumentación a la aplicación que serializa los objetos y registra su tamaño serializado.

El código de ejemplo siguiente intenta estimar el tamaño promedio de un único objeto. El objeto serializado se denomina obj. La variable length se usa para registrar la longitud. Si se producen problemas al obtener el tamaño con NetDataContractSerializer, se usa BinaryFormatter en su lugar. Puede ajustar este método para facilitar su uso. En dicho caso, obj se pasaría como un parámetro y length se devolvería desde el método.

// requires following assembly references:
//
//using System.Xml;
//using System.IO;
//using System.Runtime.Serialization;
//using System.Runtime.Serialization.Formatters.Binary;
//
// Target object “obj”
//
long length = 0;

MemoryStream stream1 = new MemoryStream();
using (XmlDictionaryWriter writer = 
    XmlDictionaryWriter.CreateBinaryWriter(stream1))
{
    NetDataContractSerializer serializer = new NetDataContractSerializer();
    serializer.WriteObject(writer, obj);
    length = stream1.Length; 
}

if (length == 0)
{
    MemoryStream stream2 = new MemoryStream();
    BinaryFormatter bf = new BinaryFormatter();
    bf.Serialize(stream2, obj);
    length = stream2.Length;
}

Nota

Tenga en cuenta que si tuviese una configuración de clúster de caché de prueba, sería posible agregar elementos a la memoria caché y usar el comando de Windows PowerShell, Get-CacheStatistics, para buscar el tamaño de uno o más objetos agregados en caché. O bien, podría dividir el tamaño de varios objetos en caché mediante el recuento de objetos en caché. Puede elegir entre recolectar estimaciones a través de código o de pruebas.

Si tiene previsto usar el almacenamiento en caché de AppFabric para el estado de sesión, es importante comprender que el proveedor de SQL Server para el estado de sesión ASP.NET siempre usa BinaryFormatter en lugar de NetDataContractSerializer. A veces, los objetos serializados mediante la clase NetDataContractSerializer pueden tener un tamaño mucho mayor que el tamaño serializado de objetos que usan BinaryFormatter. Esto es importante si se tiene en cuenta el tamaño de los objetos de estado de sesión en SQL Server, ya que no es posible usar dicho tamaño y suponer que será igual en la memoria caché. Podría multiplicar ese tamaño por seis para obtener una estimación general. Para obtener una mejor estimación, use el código anterior en los objetos almacenados en el estado de sesión. Con los datos recolectados hasta ahora, puede comenzar a formular los requisitos totales de memoria. En este paso se incluyen las subtareas siguientes:

1. Céntrese en un tipo de objeto (por ejemplo, el objeto Shopping Cart).

2. Para dicho objeto, obtenga el tamaño de objeto serializado promedio.

3. A continuación, agregue 500 bytes al tamaño promedio para tener en cuenta la sobrecarga de almacenamiento en caché.

4. Multiplique ese tamaño por el número máximo de objetos activos. De este modo, obtendrá los requisitos de memoria de almacenamiento en caché total para ese tipo de objeto.

5. Agregue una sobrecarga estimada para las estructuras de almacenamiento en caché internas (5%).

6. Repita estos pasos para cada tipo de objeto identificado.

7. Agregue los resultados para obtener los requisitos de memoria de almacenamiento en caché total.

Durante este proceso, tenga en cuenta que hay aproximadamente 0,50 KB de sobrecarga por objeto y que debería agregar a las estimaciones de tamaño. Además, existen otras estructuras de datos internas que requieren memoria en caché. Las regiones, las etiquetas y las notificaciones requieren memoria adicional para su administración. En los cálculos de ejemplo, se agrega un 5% del total para tener en cuenta estas estructuras internas, pero podría ser más o menos en función del uso que se hace de las características de almacenamiento en caché.

Llegado a este punto, debería considerar el impacto de una característica específica de almacenamiento en caché de AppFabric, la alta disponibilidad. Esta característica crea copias de los elementos en caché en servidores secundarios. Esto significa que si se produce un error en un único servidor de caché, el servidor de caché secundario toma el control y no se pierden los datos. Si opta por usar la característica de alta disponibilidad, deberá doblar las estimaciones de memoria. También deberá usar Windows Server 2008 Enterprise Edition o superior. Tenga en cuenta que la característica de alta disponibilidad se realiza en el nivel de caché con nombre. Esto significa que si creara dos cachés con nombre en el mismo clúster, no necesariamente sería necesario usar la alta disponibilidad para cada caché. La aplicación podría colocar algunos elementos en la memoria caché con nombre con alta disponibilidad y algunos en la memoria con nombre sin alta disponibilidad. Esto podría ayudar a sacar el máximo partido de los recursos de memoria. Por lo tanto, es importante conocer la decisión acerca de las características de alta disponibilidad, ya que dobla los requisitos de memoria para las memorias caché que la usan.

En modo de ejemplo, a continuación se proporciona una tabla en la que se evalúan los requisitos de los datos de actividad y los datos de referencia en la misma aplicación. Según el escenario, podría realizar esta estimación en el nivel de objeto o de aplicación. Simplemente agregaría más columnas a este ejemplo y les asignaría las etiquetas correspondientes.

Objeto para analizar:	Datos de actividad	Datos de referencia
Tamaño de objeto serializado promedio:	250 KB	60 KB
Sobrecarga de clúster de caché por objeto:	0,5 KB	0,5 KB
Tamaño de objeto serializado promedio ajustado:	250,5 KB	60,5 KB
Máx. objetos activos:	35.000 (aprox.)	68.000 (aprox.)
Requisitos de memoria de almacenamiento en caché:	8,4 GB	3,9 GB
¿Alta disponibilidad habilitada?	16,8 GB	No
Sobrecarga de estructuras de datos internas (5%):	0,8 GB	0,2 GB
Requisitos de memoria total:	17,6 GB	4,1 GB

La agregación de estas estimaciones forma los requisitos de memoria iniciales del clúster de caché. En este ejemplo, el total es 21,7 GB. Con esta estimación podrá comenzar a tener en cuenta otros aspectos, incluida la infraestructura física, los requisitos del contrato de nivel de servicio y las opciones de configuración de AppFabric.

Tercer paso: Comprender la infraestructura física y los recursos de hardware

Es importante comprender la infraestructura física y la disponibilidad de los recursos. A continuación se proporcionan algunas preguntas comunes:

1. ¿Podrá suministrar equipos físicos o máquinas virtuales?

2. Si tiene hardware existente, ¿cuáles son las configuraciones de los equipos (por ejemplo, 8 GB de RAM, Quad-Core)?

3. ¿El clúster de caché se situará en el mismo centro de datos que los servidores de aplicación?

4. ¿Cuáles son las capacidades de conexión a redes?

Si está considerando el uso de máquinas virtuales para los servidores de caché, hay varias consideraciones que debería tener en cuenta. Por ejemplo, deberá considerar el impacto que tendrá el hecho de tener varias máquinas virtuales en el mismo equipo físico. Varias máquinas virtuales pueden compartir la misma tarjeta de red, lo que aumenta la posibilidad de que se produzcan cuellos de botella en la red. Además, es posible que se haya configurado la característica de alta disponibilidad entre los hosts caché principal y secundario que son máquinas virtuales en el mismo equipo físico. Si se produjera un error en dicho equipo físico, no quedaría ninguna copia de los datos. Para obtener más información, vea la Guía para la ejecución de la memoria caché de AppFabric en una máquina virtual.

No hay especificaciones recomendadas para los equipos existentes. No obstante, para clústeres de caché de gran tamaño, se ha observado que los equipos Quad-Core con 16 GB de RAM funcionan bien. Por lo general, el planeamiento de la cantidad correcta de memoria física y carga de red son las consideraciones más importantes.

Tanto para equipos físicos como para máquinas virtuales, se debe tener en cuenta la ubicación del clúster de caché a los servidores de aplicación o web que usan la memoria caché. Si se encuentran en centros de datos independientes, debería asegurarse de que la latencia entre ellos no tendrá un impacto negativo en el rendimiento. Llegado a este punto, podría resultar tentador usar los servidores de aplicación o web como servidores de caché. Aunque esto sea posible, no es una solución admitida. En primer lugar, las subidas de uso de los recursos que provocan servicios como IIS en estos equipos podrían afectar al clúster de caché. En segundo lugar, el servicio de almacenamiento en caché supone que reside en un servidor dedicado y podría potencialmente usar una cantidad de memoria mucho mayor que la especificada.

En cuanto a las capacidades de red, debería evaluar la carga de red esperada y compararla con la infraestructura. En primer lugar, debería saber la cantidad de datos que se espera que gestionará cada servidor de caché y si las capacidades de la tarjeta de red son suficientes. De lo contrario, es posible que necesite más servidores de caché. Por ejemplo, considere un escenario en el que el tamaño de objeto en caché promedio es 500,5 KB y se producen 240 operaciones por segundo en el clúster de caché. Si se usara un único host de caché, los resultados serían los siguientes:

Número de operaciones de lectura y escritura de objeto por segundo:	240
Número de equipos del clúster de caché:	1
Número de operaciones de caché por equipo por segundo:	240
Tamaño de objeto promedio:	500,5 KB
Tamaño de los datos transmitidos por segundo:	240 * 500,5 = 117,3 Mbps

Si cada equipo tuviera una tarjeta de red de 1 Gbps, el rendimiento máximo sería 119 Mbps, aproximadamente. El valor calculado de 117,3 Mbps seguramente desbordaría ese servidor único. Esto aumenta la probabilidad de que se produzcan cuellos de botella en la red. Sin embargo, si se usaran tres equipos en el clúster de caché, una distribución equitativa de las solicitudes de caché haría que cada servidor recibiera un tercio de la carga.

Considere también la utilización de red de los servidores de aplicación que acceden al clúster de caché. Si intercambiaran un gran volumen de datos con otros sistemas, debería considerar crear una red dedicada entre los servidores de aplicación y el clúster de caché. Esto requiere el montaje de una tarjeta de red adicional en cada servidor de aplicaciones para este fin.

La última consideración de red es si ésta puede gestionar la carga requerida a lo largo de toda la ruta. Disponer simplemente de una tarjeta de red de 1 Gbps en cada servidor de caché no es suficiente. El conmutador y otros puntos a lo largo de la red también deben poder gestionar la carga. Trabaje con el departamento de operaciones para satisfacer este requisito.

Cuarto paso: Finalizar el contrato de nivel de servicio de rendimiento requerido para todas las aplicaciones

Antes de decidir en la configuración final, también debe comprender los requisitos empresariales, incluidos los contratos de nivel de servicio (SLA) relacionados con el rendimiento y la confiabilidad. En la práctica, este paso influye en la decisión sobre el número de clústeres de caché y el número de hosts de caché de cada clúster.

Por ejemplo, si hay una aplicación crítica que usa un clúster de caché, es posible que sea conveniente aislar dicho clúster de otras aplicaciones de menor prioridad. Estas aplicaciones de menor prioridad podrían usar más recursos de memoria, red o CPU que afectarían negativamente a la aplicación crítica.

A continuación se indican factores específicos que influyen en esta decisión:

• La seguridad se mantiene en el nivel del clúster de caché. Si un usuario tiene acceso al clúster de caché, podrá potencialmente acceder a cualquiera de los datos que residan en él (suponiendo que el usuario conociese el nombre de caché y la clave que se deben solicitar). Si necesita una configuración de seguridad diferente para distintos tipos de datos, puede tener sentido contar con clústeres de caché independientes. Para obtener más información, vea Administración de la seguridad.

• La expulsión de los elementos no expirados se produce cuando la memoria alcanza un nivel elevado de marca de agua. La subestimación de la cantidad de memoria necesaria para una memoria caché podría afectar a todas las memorias caché del clúster. Cuando se produce una expulsión debido a una carga excesiva de la memoria, se produce para todas las memorias caché, incluso si la responsable es una sola memoria caché. Esta situación se podría mitigar algo mediante la creación de cachés no expulsables, pero esto se debe realizar con cuidado. Para obtener más información, vea Caducidad y expulsión.

• El uso de clústeres de caché independientes puede facilitar la administración hasta cierto punto. Es posible que no desee administrar clústeres independientes para 100 cachés diferentes. Sin embargo, podría ser de utilidad disponer de clústeres de caché independientes para dos memorias caché de gran tamaño diferentes, ya que podrá administrarlas, escalarlas y supervisarlas de manera separada.

Por último, algunos requisitos podrían implicar consideraciones de latencia y rendimiento. Para obtener instrucciones y resultados de prueba sobre esta decisión, vea la nota del producto de Grid Dynamics. Por ejemplo, puede comparar los requisitos de rendimiento del clúster de caché con los resultados de prueba publicados del documento de Grid Dynamics. Su investigación podría indicar que no dispone de servidores suficientes para satisfacer los objetivos de rendimiento. Es importante reconocer que esta investigación podría no coincidir exactamente con sus tipos y tamaños de objeto y con su estructura física y lógica. Sin embargo, proporciona resultados de prueba comprobados que pueden ayudarle a tomar una decisión informada.

Quinto paso: Identificar las características y opciones de configuración adecuadas de AppFabric

Esta parte del proceso considera las opciones de configuración específicas del almacenamiento en caché de AppFabric, así como la arquitectura de un clúster de caché de AppFabric. Incluso si ha recolectado todos los datos empíricos y empresariales correctos, aún es posible planear de manera incorrecta si no se toman en cuenta las opciones de configuración del almacenamiento en caché de AppFabric.

En la tabla siguiente se proporciona una variedad de características de almacenamiento en caché de AppFabric y las consideraciones asociadas para el planeamiento de capacidad.

Regiones	Puede crear varias regiones, pero cada una de ellas existe en un único host de caché. Para sacar partido de la memoria caché distribuida, las aplicaciones deben usar varias regiones. Tenga en cuenta que todas las llamadas que no especifiquen regiones, usarán automáticamente regiones predeterminadas de manera interna. Cada host de caché del clúster de caché debe poder hospedar el tamaño máximo de la región más grande.
Notificaciones	Las memorias caché pueden habilitar notificaciones y los clientes caché pueden recibir dichas notificaciones. Esto agrega tráfico de red adicional y aumenta la utilización del procesador en el servidor. El efecto varía en función del intervalo de notificación y el número de notificaciones que se envíen. Un número elevado de notificaciones en intervalos muy cortos podría afectar al rendimiento y la escabilidad. No existen directrices fijas para la estimación de este impacto, por lo que deberá observase durante las pruebas.
Caché local	La memoria caché local mejora el rendimiento al almacenar en caché los objetos en los clientes y en el servidor. Tenga en cuenta el impacto en la memoria de los equipos clientes al usar caché local. Esta característica no afecta al planeamiento de capacidad del servidor en cuanto a memoria, ya que todos los elementos almacenados en caché de forma local también existen en el servidor. Sin embargo, si se usan notificaciones para la invalidación de la memoria caché local, el procesamiento de notificaciones podría afectar al servidor.
Diseño y configuración de la aplicación cliente	El diseño de la aplicación cliente puede afectar al rendimiento general. Por ejemplo, debería almacenar los objetos DataCacheFactory que cree para la reutilización en lugar de volver a crearlos para cada llamada. También podría sacar ventaja de la creación de un objeto DataCacheFactory por subproceso. O bien, si comparte un único objeto DataCacheFactory para varios subprocesos, considere aumentar el valor de MaxConnectionsToServer. Esto aumenta el número de conexiones a los servidores caché por DataCacheFactory.
Alta disponibilidad	Tal como se ha indicado anteriormente, las memorias caché que usan la característica de alta disponibilidad requieren que se doble el requisito de memoria calculado. Sin embargo, esta característica también requiere un mínimo de tres servidores. Si se produce un error en un servidor, debe haber dos servidores restantes para admitir las copias principal y secundaria de cada elemento después del error. Tenga en cuenta que esta característica requiere Windows Server 2008 Enterprise Edition o superior en todos los servidores.
Cachés con nombre	En estos momentos, hay un límite de 128 cachés con nombre. Esto se convierte en una decisión de planeamiento de capacidad cuando existen aplicaciones que requieren más que este número establecido. Llegado a ese punto, necesitará más de un clúster de caché o deberá diseñar las aplicaciones de modo que usen menos cachés. Otra estrategia es crear mediante programación regiones con cachés con nombre.
Almacén de configuración XML	Cuando use una ubicación de red compartida para el almacén de configuración del clúster de caché, deberá disponer de al menos tres servidores del clúster designados como hosts principales. Para obtener más información sobre los motivos, vea Actualización de servidores de caché.

No debería sorprender el hecho de que una de las opciones de configuración más importantes que se debe comprender es la configuración de memoria de cada host de caché. Puede ver la configuración de memoria predeterminada de cada host de caché mediante el comando de Windows PowerShell Get-CacheHostConfig.

Nota

Para obtener información acerca del uso de los comandos de Windows PowerShell para el almacenamiento en caché, vea Tareas habituales de administración de clústeres de caché.

En la captura de pantalla siguiente se muestran los resultados de Get-CacheHostConfig en un equipo con 4 GB de RAM.

De manera predeterminada, la cantidad de memoria reservada para la memoria caché de un servidor dado es el 50% del total de memoria RAM. En este ejemplo, la mitad de la memoria RAM es 2 GB. La cantidad restante de memoria está disponible para el sistema operativo y los servicios. Incluso en equipos con mucho más memoria, es recomendable conservar esta configuración predeterminada. Tal como se indicó anteriormente, el servicio de almacenamiento en caché supone que se ejecuta en un equipo dedicado y podría usar mucho más memoria que la asignada para la memoria caché. Si bien parte del uso de esta memoria se debe al diseño interno del servicio de almacenamiento en caché, una parte también está relacionada con la administración de la memoria y la recolección de elementos no usados de .NET. Incluso cuando la memoria se libera en una aplicación .NET, debe esperar hasta que se libere la recolección de elementos no usados de la memoria del proceso. El proceso requiere un búfer de memoria física para tener en cuenta la naturaleza no determinista de la recolección de elementos no usados.

Una vez que haya comprendido el impacto de la recolección de elementos no usados, podrá ver que las cargas de trabajo con un porcentaje y una frecuencia elevados de operaciones de escritura necesitarán un búfer más grande de memoria para tener en cuenta los ciclos de recolección de elementos no usados. Esta consideración no se aplica a las cargas de trabajo que son principalmente de solo lectura. En dicho caso, podría aumentar la cantidad de memoria reservada para el almacenamiento en caché en algunos casos. Por ejemplo, en un equipo con 16 GB, podría reservar 12 GB para la configuración del tamaño de caché (en lugar del valor predeterminado de 8 GB), de modo que se proporcionarán 4 GB de sobrecarga para el sistema operativo y los servicios. Esto supone que se trata de un equipo dedicado para el servicio de almacenamiento en caché, que es la única configuración admitida actualmente. En este ejemplo, debería realizar una prueba de esta configuración de memoria con la carga anticipada. Si la asignación de memoria es demasiada agresiva, las pruebas indicarán este error mediante problemas relacionados con la memoria, tal como la expulsión o limitación. Para obtener más información, vea Solución de problemas del servidor (Almacenamiento en caché de Windows Server AppFabric). En el ejemplo siguiente se usa el comando Set-CacheHostConfig para establecer el tamaño de caché en 12 GB en un servidor con el nombre Server1:

Set-CacheHostConfig -HostName Server1 -CachePort 22233 -CacheSize 12288

El otro elemento que se debe observar en los resultados de Get-CacheHostConfig es los valores de marca de agua. El valor LowWatermark predeterminado es un 70% de la configuración del tamaño de caché. Cuando la memoria en caché alcanza el valor de LowWatermark, el servicio de almacenamiento en caché empieza a expulsar los objetos expirados. Esto está bien, ya que esos objetos no son accesibles de todos modos.

El valor HighWatermark predeterminado es un 90% de la configuración del tamaño de caché. Al alcanzar el nivel HighWatermark, los objetos se expulsan independientemente de si han expirado hasta que la memoria vuelva al nivel LowWatermark. Evidentemente, esto podría afectar al rendimiento, así como provocar una experiencia de usuario inadecuada.

Es recomendable planear el uso de la memoria caché en el nivel LowWatermark para evitar la posibilidad de alcanzar el valor de HighWatermark. Para obtener una descripción más detallada, vea Caducidad y expulsión.

Sugerencia

Los ciclos de recolección de elementos no usados pueden provocar un retraso leve, que con frecuencia se pueden observar en los errores de reintento. Por este motivo, es recomendable que cada host de caché tenga 16 GB o menos de memoria. Los equipos con más de 16 GB de RAM pueden experimentar pausas más largas durante los ciclos completos de recolección de elementos no usados. Dicho esto, no existen restricciones en cuanto al uso de más memoria por host de caché. Una carga de trabajo que sea principalmente de solo lectura podría experimentar con menos frecuencia ciclos de recolección de datos no usados. La mejor manera de determinar esto es a través de las pruebas de carga.

En un ejemplo anterior, se calculó una estimación de 21,7 GB para el requisito de memoria de almacenamiento en caché total. Dado que se desea alta disponibilidad, debe haber al menos tres servidores. Se debe suponer que cada servidor tiene 16 GB de RAM. En este ejemplo, se conservará la configuración de tamaño de caché predeterminada de 8 GB en cada servidor. Tal como se mencionó anteriormente, el valor de LowWatermark (70%) debe ser la memoria objetivo disponible en cada servidor. Esto significa que cada servidor de caché tiene una estimación de 5,6 GB de memoria. Con estos factores, en la tabla siguiente se muestra que los cuatro servidores proporcionarían 22,4 GB de memoria de almacenamiento en caché y cumplirían el requisito de 21,7 GB.

Requisito de memoria total	21,7 GB
Memoria inicial (host de caché)	16 GB
Configuración de tamaño de caché (host de caché)	8 GB
Límite mínimo (host de caché)	70%
Objetivo de memoria ajustada por host de caché	5,6 GB
Total de memoria en clúster de caché (3 equipos)	5,6 GB * 4 servidores = 22,4

Nuevamente, recuerde que también puede usar los resultados publicados en la nota del producto de Grid Dynamics para comprobar esta estimación en relación con los objetivos de rendimiento y latencia. Dichos resultados podrían llevarle a modificar ligeramente esta estimación inicial, tal como la adición de otro servidor de caché. Lo importante es que debería usar los recursos disponibles como éste para tomar una decisión informada.

Herramienta de planeamiento de capacidad

Una hoja de cálculo es una herramienta lógica para los pasos de planeamiento de capacidad de las secciones anteriores. Se ha creado una hoja de cálculo de ejemplo que se puede descargar aquí. Las entradas con asterisco son elementos que debería modificar en función del planeamiento y los recursos. Los demás cálculos los realiza la hoja de cálculo.

En la primera parte de la hoja de cálculo se especifica la configuración de servidor de cada host de caché. Tenga en cuenta que puede modificar esta parte del proceso de planeamiento y observar las diferencias en los cálculos finales. En la captura de pantalla siguiente se muestra esta primera sección.

Importante
A menos que use los valores de instalación predeterminados, es su responsabilidad usar el comando Set-CacheHostConfig en cada host de caché para aplicar la configuración de los valores CacheSize y LowWatermark.

En la segunda sección puede completar las estimaciones para distintos tipos de objetos. En la hoja de cálculo de ejemplo, se usan solo dos secciones para “Datos de actividad” y “Datos de referencia”. A continuación, se proporciona una serie de columnas, cuyos nombres puede cambiar según el nivel de granularidad que usa en el planeamiento (objeto, categoría, aplicación, etc.). En la captura de pantalla siguiente se muestra esta segunda sección.

En la tercera sección se realiza una estimación de los requisitos de red. Deberá completar los tamaños de objeto de lectura o escritura promedio y el máximo de operaciones de lectura o escritura por segundo. En esta sección se calculan los requisitos máximos de ancho de banda de la red para el tipo de objeto correspondiente. Esta información se puede usar para obtener una idea general de si el agrupamiento de los equipos y las tarjetas de red puede soportar la carga. Tal como se indicó en secciones anteriores, también debería mirar al ancho de banda en toda la ruta de red. En la captura de pantalla siguiente se muestra esta tercera sección.

En la última sección se agregan los requisitos en la secciones de memoria y red. A continuación, se usa la configuración del equipo especificado de la primera sección para calcular el número de servidores. El campo “Additional Servers” permite aumentar este total calculado si fuera necesario. Por ejemplo, si los cálculos especificaron que solo se necesitan dos servidores, puede agregar un servidor adicional al total final para poder admitir la característica de alta disponibilidad. En la captura de pantalla siguiente se muestra esta última sección.

Nota

En las capturas de pantalla anteriores se usan cifras similares a las del ejemplo de este documento, pero el número de servidores estimados es de tres en lugar de cuatro. Esto se debe a que en la hoja de cálculo el valor Cache Size Setting(Set-CacheHostConfig) se establece en 12 GB para demostrar la configuración personalizada. Si cambia este valor a 8 GB, los resultados serán similares a los observados en las secciones anteriores de este documento.

Próximos pasos en el planeamiento de capacidad

En la sección anterior se presentó una metodología para determinar una estimación inicial del número de clústeres de caché, el número de hosts de caché de cada clúster y la configuración de estos últimos. Sin embargo, debe reconocer que se trata de una estimación que podría cambiar en función de las pruebas realizadas y un seguimiento continuo.

Si decide seguir adelante con los planes para usar el almacenamiento en caché de AppFabric, puede crear una prueba de concepto para tener una idea de cómo el almacenamiento en caché de AppFabric funcionaría con su solución. Luego, podría configurar un clúster de caché de prueba para realizar pruebas en el entorno. En función de los resultados de dichas pruebas, podrá realizar cambios adicionales en la configuración para satisfacer los requisitos de capacidad, rendimiento y escabilidad. En la sección siguiente se describen métricas continuas específicas que podría analizar durante las pruebas y en producción.

Seguimiento de los requisitos continuos de la capacidad de almacenamiento en caché

El planeamiento de capacidad del almacenamiento en caché no es una ciencia exacta. Muchas de las cifras obtenidas se incorporan en conclusiones que, en sí, son estimaciones. Además, el uso y los patrones de las aplicaciones pueden cambiar con el tiempo. Por consiguiente, debería realizar un seguimiento de los indicadores de rendimiento para asegurarse de que el clúster de caché satisface los requisitos de capacidad. Un planeamiento de capacidad correcto es un proceso continuo que se sigue realizando tanto en entornos de prueba como de producción.

La herramienta Monitor de rendimiento es la mejor manera de realizar un seguimiento de la capacidad de manera continua. En cada host de caché, es recomendable realizar un seguimiento de los contadores siguientes:

Categoría de supervisión	Contadores del Monitor de rendimiento
Memoria	Almacenamiento en caché de AppFabric:Host\Total de bytes de tamaño de datos Almacenamiento en caché de AppFabric:Host\Total de objetos expulsados Almacenamiento en caché de AppFabric:Host\Total de ejecuciones de expulsión Almacenamiento en caché de AppFabric:Host\Total de memoria desalojada Almacenamiento en caché de AppFabric:Host\Recuento total de objetos Memoria .NET CLR(DistributedCacheService)\Nº colecciones Gen 0 Memoria .NET CLR(DistributedCacheService)\Nº colecciones Gen 1 Memoria .NET CLR(DistributedCacheService)\Nº colecciones Gen 2 Memoria .NET CLR(DistributedCacheService)\Nº objetos anclados Memoria .NET CLR(DistributedCacheService)\% tiempo en GC Memoria .NET CLR(DistributedCacheService)\Tamaño pila objetos grandes Memoria .NET CLR(DistributedCacheService)\Tamaño pila Gen 0 Memoria .NET CLR(DistributedCacheService)\Tamaño pila Gen 1 Memoria .NET CLR(DistributedCacheService)\Tamaño pila Gen 2 Memoria\Mbytes disponibles
Red	Interfaz de red(*)\Bytes recibidos por segundo Interfaz de red(*)\Bytes enviados por segundo Interfaz de red(*)\Ancho de banda actual
CPU	Proceso(DistributedCacheService)\% tiempo de procesador Proceso(DistributedCacheService)\Recuento subprocesos Proceso(DistributedCacheService)\Conjunto en funcionamiento Proceso(_Total)\% tiempo de procesador
Rendimiento	Almacenamiento en caché de AppFabric:Host\Total de solicitudes de clientes Almacenamiento en caché de AppFabric:Host\Total de solicitudes de clientes por segundo Almacenamiento en caché de AppFabric:Host\Total de solicitudes Get Almacenamiento en caché de AppFabric:Host\Total de solicitudes Get por segundo Almacenamiento en caché de AppFabric:Host\Total de solicitudes Get Almacenamiento en caché de AppFabric:Host\Total de solicitudes Get por segundo Almacenamiento en caché de AppFabric:Host\Total de solicitudes GetAndLock Almacenamiento en caché de AppFabric:Host\Total de solicitudes GetAndLock por segundo Almacenamiento en caché de AppFabric:Host\Total de solicitudes de lectura Almacenamiento en caché de AppFabric:Host\Total de solicitudes de lectura por segundo Almacenamiento en caché de AppFabric:Host\Total de operaciones de escritura Almacenamiento en caché de AppFabric:Host\Total de operaciones de escritura por segundo
Varios	Almacenamiento en caché de AppFabric:Host\Porcentaje de error de caché Almacenamiento en caché de AppFabric:Host\Total de objetos caducados Almacenamiento en caché de AppFabric:Host\Total de notificaciones entregadas

Muchos de los contadores que se indican aquí se relacionan directamente con el proceso de planeamiento de capacidad. Por ejemplo, hay varios contadores de memoria. “Memoria\Mbytes disponibles” muestra la cantidad de memoria física restante en el equipo, en megabytes. Si este contador cae por debajo del 10% del total de memoria física, existe una importante probabilidad de que se produzca una limitación. Para obtener más información, vea Solución de problemas de limitaciones. Otros contadores son específicos de las características de almacenamiento en caché. “Almacenamiento en caché de AppFabric:Host\Total de ejecuciones de expulsión” indica la frecuencia de expulsión de memoria. A medida que los niveles de memoria superen el límite máximo, este contador señalará estas ejecuciones de expulsión a medida que la memoria vuelva al límite mínimo. De manera similar, los demás contadores están asociados con el proceso de análisis del planeamiento de capacidad que se describe en las secciones anteriores de este documento.

Tenga en cuenta que los contadores de proceso del servicio DistributedCacheService y el contador Procesador del equipo también se capturan. Una elevada utilización del procesador puede afectar negativamente al rendimiento del clúster de caché. Si detecta períodos de utilización elevada del procesador, es importante identificar si está relacionada con el servicio de almacenamiento en caché (DistributedCacheService.exe) o con otro proceso del equipo.

Además de la herramienta Monitor de rendimiento, puede usar los comandos Windows PowerShell que se instalan con AppFabric. Muchos de estos comandos se pueden usar para realizar un seguimiento del estado del clúster de caché. Para obtener más información, vea Herramientas de seguimiento de estado y Registros y contadores de la memoria caché de AppFabric.

Vea también

Otros recursos

Instalación de Windows Server AppFabric
Documentación MSDN sobre el almacenamiento en caché de Windows Server AppFabric
Guía de programación para el almacenamiento en caché de AppFabric
Configuración de un proveedor de estado de sesión ASP.NET
Opciones de almacenamiento de la configuración de clúster
Guía de administración e implementación de características de almacenamiento en caché de Windows Server AppFabric
Vínculos y recursos para Windows Server AppFabric y Windows Azure AppFabric

  2011-12-05