Después de cambiar un par de llamadas de la base de datos a caché, en realidad tuvimos un rendimiento peor. Notamos un gran salto en el tiempo CLR y el tiempo de respuesta según la nueva reliquia. Consulte el gráfico adjunto para el salto (el caché se introdujo 1/5 a las 0:00). Lossolamento que ha cambiado ha sido la introducción de Azure App Fabric Cache. Nuestro cliente de caché utiliza un patrón singleton, por lo que solo hay uno para la instancia del servicio web. la fábrica de caché se crea una vez y luego se almacena para que no tengamos que evitar la sobrecarga de abrir la conexión cada vez.

Además, NewRelic informa que el caché está tardando en promedio 15 ms. En muchos casos, 15 ms pueden ser más lentos que la base de datos !!!!

nto El objeto que estamos pegando consta en caché de dos conjuntos de bytes, uno tiene una longitud de aproximadamente 421 y el otro tiene una longitud de 8.

No entiendo realmente por qué con la introducción de caché vemos un mayor tiempo de respuesta. ¿Una matriz de bytes no es compatible con caché?

my clase se ve así (las únicas dos propiedades que se pueblan antes de ingresar a la clase son las matrices de dos bytes; todo lo demás se deja a los valores predeterminados)

[Table]
public class GameState
{
    [Column(IsPrimaryKey = true, IsDbGenerated = true, AutoSync = AutoSync.OnInsert)]
    public int Id { get; set; }

    [Column(UpdateCheck = UpdateCheck.Never, Name = "game_id")]
    public int GameId { get; set; }

    [Column(UpdateCheck = UpdateCheck.Never, Name = "player_id")]
    public int PlayerId { get; set; }

    [Column(UpdateCheck = UpdateCheck.Never, DbType = "VarBinary(max)")]  //has a length around 421
    public byte[] State { get; set; }

    [Column(UpdateCheck = UpdateCheck.Never, IsDbGenerated = true, AutoSync = AutoSync.OnInsert)]
    public DateTime Created { get; set; }

    [Column(UpdateCheck = UpdateCheck.Never, Name = "update", IsDbGenerated = true, DbType = "timestamp")] //has a length of 8
    public byte[] TimeStamp { get; set; }
}

Gracia

ACTUALIZA

Hablamos con varios ingenieros de Microsoft y nadie nos pudo ayudar por qué fue tan lento. Un ingeniero informó que la capa de caché se creó sobre SQL Azure, lo que explicaba los altos tiempos de solicitud. Otro ingeniero negó esa afirmación, pero no estaba exactamente seguro de cómo se implementó el almacenamiento en caché compartido.

Nunca pudimos hacer que el caché azul funcionara rápidamente y finalmente cambiamos de Azure a Amazon ec2. Una vez en Amazon ec2 en hardware comparable, nuestro tiempo de respuesta se redujo a aproximadamente 60-70 ms.

ara cualquier otra persona al considerar esto, esto fue lo que aprendimos en el cambio.

SQL Azure es un alojamiento compartido de bases de datos. No obtienes tu propia base de datos, estás en un servidor con un montón de otras bases de datos y si tienes algún tipo de tráfico decente, serás estrangulado. Seguían contándonos sobre alguna historia exitosa de compra de boletos, pero en ese escenario tenían 750 DB para procesar las transacciones. Sharding no es divertido, y una mejor historia de éxito es que manejó todas esas solicitudes con 1DB.

Usamos SSL, y hacer que IIS administre el SSL realmente mata su CPU. Amazon hace que su ELB haga el ssl y luego sus cajas IIS no tienen que hacerlo. Esto liberó los cuadros de IIS para manejar solicitudes más rápido.

Amazon te permite ejecutar memcache. Memcache es asombroso. Tener una capa de caché rápida y ligera (capaz de crecer más allá de 4GB), quitó una carga tremenda de nuestra base de datos.

Regresamos el cambio en enero de 2012, por lo que es posible que Azure haya mejorado en el último año, sin embargo, no tengo planes de darle una segunda oportunidad.