После переключения нескольких обращений к базе данных к кешу у нас фактически была худшая производительность.Мы заметили огромный скачок времени CLR и времени отклика в соответствии с новой реликвией.Пожалуйста, смотрите прикрепленный график для перехода (кеш был введен 1/5 в 0:00).Изменением only стало появление Azure App Fabric Cache.Наш кеш-клиент использует одноэлементный шаблон, поэтому для экземпляра веб-сервиса есть только один.фабрика кеша создается один раз, а затем сохраняется, поэтому мы не берем на себя издержки, связанные с открытием соединения каждый раз.
Более того, NewRelic сообщает, что кэш начинает работатьв среднем 15 мс.Во многих случаях 15 мс могут быть медленнее, чем база данных !!!!
nto Объект, к которому мы привязываем, я кеширую из двух байтовых массивов, один имеет длину около 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; }
}
Спасибо
ОБНОВЛЕНИЕ
Мы поговорили с несколькими инженерами Microsoft, и никто не смог помочь нам понять, почему это так медленно.Один инженер сообщил, что уровень кэша был построен поверх SQL Azure, что объясняет большое время запросов.Другой инженер опроверг это утверждение, но не совсем знал, как реализовано Shared Caching.
Нам так и не удалось заставить работать кэш Azure быстро и, в конечном итоге, переключиться с Azure на Amazon ec2.Однажды на Amazon ec2 на сопоставимом оборудовании наше время отклика упало примерно до 60-70 мс.
Для всех, кто задумывался над этим, это то, что мы узнали на коммутаторе.
SQL Azure - это хостинг с общей БД.Вы не получаете свою собственную БД, вы находитесь на сервере с кучей других БД, и если у вас есть какой-либо приличный трафик, вы получите удушение.Они продолжали рассказывать нам об истории успеха покупки билетов, но в этом сценарии у них было 750 БД для обработки транзакций.Разделение - это не весело, и более удачным примером является то, что вы обрабатывали все эти запросы с помощью 1DB.
Мы используем SSL, а управление IIS через SSL действительно убивает ваш ЦП.Amazon заставляет ваш ELB выполнять ssl, и тогда ваши IIS-блоки не обязаны это делать.Это освободило блоки IIS для более быстрой обработки запросов.
Amazon позволяет запускать memcache.Memcache это круто.Имея молниеносный слой быстрого кэширования (способный расти намного больше 4 ГБ), мы взяли на себя огромную нагрузку на нашу БД.
Мы сделали переход еще в январе 2012 года, поэтому его возможный Azure стал лучше в прошлом годуУ меня нет планов дать ему второй шанс.