Низкая производительность с лазурным кэшем

После переключения нескольких вызовов базы данных в кеш-память мы на самом деле имели худшую производительность. Мы заметили огромный скачок времени CLR и времени отклика в соответствии с новой реликвией. См. Прилагаемый график для перехода (кэш был введен 1/5 в 0:00). Единственное, что изменилось, это введение кэш-памяти Azure App Fabric. Наш клиент кеша использует одноэлементный шаблон, поэтому для экземпляра веб-службы есть только один. кеш factory создается один раз, а затем сохраняется, поэтому мы не задерживаем накладные расходы при открытии соединения каждый раз.

Кроме того, NewRelic сообщает, что кеш занимает в среднем 15 мс. Во многих случаях 15 мс могут быть медленнее, чем база данных!!!!

nto Объект, в котором мы вставляем i-кеш-байты двух байтовых массивов, имеет длину около 421, а другая имеет длину 8.

Не понимаю, почему с введением кеша мы видим увеличенное время отклика. Является ли байтовый массив небезопасным кэш?

мой класс выглядит следующим образом (только два свойства, которые заполняются до того, как они были загружены в класс, представляют собой два байтовых массива, все остальное остается по умолчанию)

[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; }
}

Спасибо

UPDATE

Мы разговаривали с несколькими инженерами Microsoft, и никто не мог нам помочь в том, почему это было так медленно. Один инженер сообщил, что уровень кэша был построен поверх SQL Azure, что объясняло высокие времена запросов. Другой инженер отрицал это требование, но точно не знал, как было реализовано совместное кэширование.

Нам не удалось быстро получить лазурный кеш и в конечном итоге переключиться с Azure на Amazon ec2. Однажды на Amazon ec2 на сопоставимом оборудовании наше время отклика сократилось примерно до 60-70 мс.

Для кого-либо еще, рассматривающего это, это то, что мы узнали в коммутаторе.

SQL Azure - это общий хостинг БД. Вы не получаете свою собственную БД, вы находитесь на сервере с кучей других БД, и если у вас есть какой-то приличный трафик, вы получите дросселирование. Они рассказывали нам о истории успеха покупки билетов, но в этом сценарии у них было 750 БД для обработки транзакций. Sharding - не забава, и лучшая история успеха заключается в том, что вы обрабатывали все эти запросы с помощью 1DB.

Мы используем SSL, и когда IIS управляет SSL, действительно убивает ваш процессор. У Amazon ваш ELB делает ssl, а затем ваши IIS-боксы не обязательно. Это освободило ящики IIS, чтобы быстрее обрабатывать запросы.

Amazon позволяет запускать memcache. Memcache является удивительным. Обладая быстроразъемным слоем кеша (способный вырасти значительно выше 4 ГБ), мы получили огромную нагрузку на нашу БД.

Мы сделали переход обратно в jan 2012, поэтому его возможный Azure стал лучше в прошлом году, однако у меня нет никаких планов по предоставлению ему второго шанса.