performance - Almacenamiento en caché de AppFabric: uso adecuado de DataCacheFactory y DataCache

caching

Question

Estoy buscando la forma más efectiva de organizar el uso de la caché de datos y la fábrica de caché de datos para las llamadas de caché de AppFabric, para obtener entre 400 y 700 caché por carga de página (y apenas cualquier compra). Parece que usar una única DataCacheFactory estática (o posiblemente una pareja en una configuración round-robin) es el camino a seguir.

¿Invoco GetCache ("cacheName") para cada solicitud de objeto DataCache, o hago una estática en el momento en que se inicia la fábrica de DataCache y la utilizo para todas las llamadas?

¿Debo manejar excepciones, verificar códigos de falla e intentar reintentos?

¿Tengo que considerar contención cuando más de un subproceso intenta usar el almacén de memoria caché y quiere el mismo elemento (por clave)?

¿Hay algún tipo de documentación que explora adecuadamente el diseño y el uso de esto?

Alguna información que he reunido hasta ahora del foro:

http://social.msdn.microsoft.com/Forums/en-AU/velocity/thread/98d4f00d-3a1b-4d7c-88ba-384d3d5da915

"Crear la fábrica implica conectarse al clúster y puede llevar algo de tiempo. Pero una vez que tenga el objeto de fábrica y el caché con el que desea trabajar, simplemente puede reutilizar esos objetos para hacer puesta y entrar en el caché, y debe ver un rendimiento mucho más rápido ".

http://social.msdn.microsoft.com/Forums/en-US/velocity/thread/0c1d7ce2-4c1b-4c63-b525-5d8f98bb8a49

"Crear DataCacheFactory (singleton) es más efectivo que crear múltiples DataCacheFactory. No debe crear DataCacheFactory para cada llamada, sino que tendrá éxito en el rendimiento".

"Intente encapsular el algoritmo round-robin (teniendo 3/4/5 instancias de fábrica) en su singleton y compare los resultados de la prueba de carga".

http://blogs.msdn.com/b/velocity/archive/2009/04/15/pushing-client-performance.aspx

"Puede aumentar el número de clientes para aumentar el rendimiento del caché. Pero a veces, si desea tener un conjunto más pequeño de clientes y aumentar el rendimiento, un truco es usar varias instancias de DataCacheFactory. La instancia de DataCacheFactory crea una conexión con los servidores (p. .g si hay 3 servidores, creará 3 conexiones) y multiplexa todas las solicitudes de los datacaches en estas conexiones. Por lo tanto, si el volumen de envío / recepción es muy alto, estas conexiones TCP podrían tener un cuello de botella. Por lo tanto, una forma es crear múltiples instancias de DataCacheFactory y luego usar las operaciones sobre ellas ".

Aquí lo que está en uso hasta ahora ... se llama a la propiedad y si el valor de retorno no es nulo, se realiza una operación.

private static DataCache Cache
{
    get
    {
        if (_cacheFactory == null)
        {
            lock (Sync)
            {
                if (_cacheFactory == null)
                {
                    try
                    {
                        _cacheFactory = new DataCacheFactory();
                    }
                    catch (DataCacheException ex)
                    {
                        if (_logger != null)
                        {
                            _logger.LogError(ex.Message, ex);
                        }
                    }
                }
            }
        }

        DataCache cache = null;

        if (_cacheFactory != null)
        {
            cache = _cacheFactory.GetCache(_cacheName);
        }

        return cache;
    }
}

Consulte esta pregunta en el foro de Microsoft AppFabric: http://social.msdn.microsoft.com/Forums/en-AU/velocity/thread/e0a0c6fb-df4e-499f-a023-ba16afb6614f

Answer 1

¿Invoco GetCache ("cacheName") para cada solicitud de objeto DataCache, o hago una estática en el momento en que se inicia la fábrica de DataCache y la utilizo para todas las llamadas?

Supongo que realmente la respuesta debería ser; pruébelo de ambas formas y vea si hay alguna diferencia, pero un DataCache estático tiene más sentido que una llamada correspondiente a GetCache para cada llamada a Get.

Ese artículo ''Pushing Client Performance'' sugiere que hay un punto positivo en el que la cantidad de instancias de DataCacheFactory te da el máximo rendimiento más allá del cual la memoria comienza a trabajar en tu contra - es una pena que no dieron ninguna guía (o incluso una regla general) ) en donde podría estar este lugar.

No he encontrado ninguna documentación sobre cómo maximizar el rendimiento. Creo que AppFabric es demasiado nuevo para que estas directrices hayan desaparecido todavía. Eché un vistazo a los contenidos del libro Pro AppFabric , pero parece mucho más preocupado por el lado del flujo de trabajo (Dublín) de AppFabric que por el elemento de caché (Velocity).

Sin embargo, una cosa que diría: ¿hay alguna posibilidad de que guardes en caché los objetos ''más voluminosos'' para que puedas hacer menos llamadas a Get ? ¿Podría almacenar en caché colecciones en lugar de objetos individuales y luego descomprimir las colecciones en el cliente? 700 caché se obtiene por carga de página me parece ser un gran número!

Answer 2

Aquí está la respuesta de la publicación del foro:

Hola. Perdón por la respuesta demorada, pero quiero decir que estas son preguntas geniales y que probablemente serán útiles para otros.

No debería haber más de una DataCacheFactory por hilo a menos que requiera configuraciones diferentes. Por ejemplo, si configura programáticamente DataCacheFactory con la clase DataCacheFactoryConfiguration, quizás desee crear uno que tenga habilitada la memoria caché local y otra que no. En este caso, usaría diferentes objetos DataCacheFactory según la configuración que requiera para su escenario. Pero aparte de las diferencias en la configuración, no debería ver una ganancia en el rendimiento al crear múltiples DataCacheFactories.

Sobre el mismo tema, hay una configuración MaxConnectionsToServer (ya sea programática en DataCacheFactoryConfiguration o en el archivo de configuración de la aplicación como un atributo del elemento dataCacheClient). Esto determina la cantidad de chennels por DataCacheFactory que se abren en el clúster de caché. Si tiene requisitos de alto rendimiento y también ancho de banda de CPU / red disponible, aumentar esta configuración a 3 o más puede aumentar el rendimiento. No recomendamos aumentar esto sin causa o con un valor que sea demasiado alto para sus necesidades. Debería cambiar el valor y luego probar su escenario para observar los resultados. Esperamos tener más guías oficiales sobre esto en el futuro.

Una vez que tiene una DataCacheFactory, no necesita llamar a GetCache () varias veces para obtener múltiples objetos DataCache. Cada llamada a GetCache () para el mismo caché en la misma fábrica devuelve el mismo objeto DataCache. Además, una vez que tenga el objeto DataCache, no necesita continuar llamando a DataCacheFactory. Simplemente almacene el objeto DataCache y continúe usándolo. Sin embargo, no permita que se elimine el objeto DataCacheFactory. La vida del objeto DataCache está vinculada al objeto DataCacheFactory.

Nunca debe preocuparse por la contención con las solicitudes de obtención. Sin embargo, con las solicitudes Put / Add, puede haber contención si varios clientes de caché de datos están actualizando la misma clave al mismo tiempo. En este caso, obtendrá una excepción con un código de error de ERRCA0017, RetryLater y un subestado de ES0005, KeyLatched. Sin embargo, puede agregar fácilmente el manejo de excepciones y volver a intentar la lógica para intentar la actualización nuevamente cuando ocurran errores como estos. Esto se puede hacer para los códigos RetryLater con varios valores de subestado. Para obtener más información, vea http://msdn.microsoft.com/en-us/library/ff637738.aspx . También puede usar el bloqueo pesimista utilizando las API GetAndLock () y PutAndUnlock (). Si usa este método, es su responsabilidad asegurarse de que todos los clientes de caché utilicen el bloqueo pesimista. Una llamada Put () eliminará un objeto que previamente estaba bloqueado por GetAndLock ().

Espero que esto ayude. Como dije, esperamos obtener este tipo de orientación en algún contenido formal pronto. Pero es mejor compartirlo aquí en el foro hasta entonces. ¡Gracias!

Jason Roth