Comments 28
Почему не AppFabric Cache? К нему уже даже есть говтовый провайдер сессий
Его провайдер мне не подходит, все равно писать свой, для параллельного доступа к записи в сессию (я этот момент отметил в статье).
Пробовал его. Так же написал похожий провайдер, который использует только его функции как кэша. С ним все работает, скорость по моим ощущениям у него хуже чем у решения с Redis, хотя конечно тестов не делал.
Но тем кому нужно в продакшен и важна стабильность однозначно сначала его попробовать, перед использованием других компонентов и тем более написания велосипедов типа моего :)
Пробовал его. Так же написал похожий провайдер, который использует только его функции как кэша. С ним все работает, скорость по моим ощущениям у него хуже чем у решения с Redis, хотя конечно тестов не делал.
Но тем кому нужно в продакшен и важна стабильность однозначно сначала его попробовать, перед использованием других компонентов и тем более написания велосипедов типа моего :)
А вы пробовали AppFabric Cache в реальной работе?
Ну, вот сейчас в девелопменте обкатываем. А что?
Есть такой опыт. AppFabric Cache по скорости прилично уступает SQL Server'у:)
Да ладно! Для чего вы его используете и как? Если делать Select 1 запросы к sql — может и уступает, хотя тоже не поверю
Можете верить или не верить, но рекомендую все-таки проверить. В качестве теста можете сделать таблицу key-value с некластерным индексом, затолкать туда хотя бы пол миллиона записей, потом закинуть эти записи в AppFabric и вынимать. Для получения данных из Sql Server использовать BlToolkit (а то EF может сильно исказить результаты:)) или по страринке датаридером, для чистоты эксперимента. Результаты скажут сами за себя.
Скорее всего именно по этой причине ребята из StackOverflow не стали использовать у себя AppFabric в качестве кэша, а поставили сервер на Linux с Redis.
Скорее всего именно по этой причине ребята из StackOverflow не стали использовать у себя AppFabric в качестве кэша, а поставили сервер на Linux с Redis.
Использование Redis на Stackoverflow, кстати, стало достаточно весомым аргументом попробовать его.
Только что проверил: на 10 000 ключей/значений, значения уникальные, около 2кб, значения в мс
Fill cache: 8 509
Fill sql: 35 378
Read cache: 9 049
Read sql: 22 936
То же самое на 100 000 значений
Fill cache: 94 434
Fill sql: 310 625
Read cache: 82 843
Read sql: 230 575
Код теста pastebin.com/FitkGGzp
Fill cache: 8 509
Fill sql: 35 378
Read cache: 9 049
Read sql: 22 936
То же самое на 100 000 значений
Fill cache: 94 434
Fill sql: 310 625
Read cache: 82 843
Read sql: 230 575
Код теста pastebin.com/FitkGGzp
1. Какой тип колонки Key в БД?
2. Есть некластерный индекс по Key include Value?
3. Свободной оперативной памяти достаточно? Это важно и для SQL и для AppFabric, он может просто выкинуть все из кэша, если решит, что мало памяти.
4. В настройках AppFabric указано не юзать локальный кэш?
5. Чтения должны выполняться по одним и тем же ключам, т.е. сначала надо сгенерить рандомные ключи, а потом по ним тащить значения.
6. И неплохо было бы сначала выполнить холостой прогон метода, а потом с замером в цикле. JIT.
2. Есть некластерный индекс по Key include Value?
3. Свободной оперативной памяти достаточно? Это важно и для SQL и для AppFabric, он может просто выкинуть все из кэша, если решит, что мало памяти.
4. В настройках AppFabric указано не юзать локальный кэш?
5. Чтения должны выполняться по одним и тем же ключам, т.е. сначала надо сгенерить рандомные ключи, а потом по ним тащить значения.
6. И неплохо было бы сначала выполнить холостой прогон метода, а потом с замером в цикле. JIT.
1) см ниже
2) есть
3) Всего достаточно, там не так много данных
4) указано
5) да алдно, это непринципиально
6) jit тут — капля в море, ибо рассчетов нет
2) есть
3) Всего достаточно, там не так много данных
4) указано
5) да алдно, это непринципиально
6) jit тут — капля в море, ибо рассчетов нет
3. AppFabric выкидывает данные из кэша, если считает, что осталось мало памяти. Для теста это может быть важно:)
5. Даже спорить не буду:)
6. Ага, и DEBUG/RELEASE компиляция тоже пофигу.
5. Даже спорить не буду:)
6. Ага, и DEBUG/RELEASE компиляция тоже пофигу.
Оба теста выполнены в одной конфигурации и в одних условиях.
Просто признайте, что аргументов больше нет:)
Просто признайте, что аргументов больше нет:)
Sql создания таблицы
CREATE TABLE [dbo].[Cache](
[Key] [nvarchar](400) NOT NULL,
[Value] [nvarchar](max) NULL,
PRIMARY KEY NONCLUSTERED
(
[Key] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
CREATE TABLE [dbo].[Cache](
[Key] [nvarchar](400) NOT NULL,
[Value] [nvarchar](max) NULL,
PRIMARY KEY NONCLUSTERED
(
[Key] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
1. Key не надо делать nvarchar(400) — это слишком жестко. Лучше varchar(50).
2. Колонка value должна быть include в индексе.
Какой план?
2. Колонка value должна быть include в индексе.
Какой план?
> Процесс установки Redis опущен.
Упущен. Детали упускают.
Упущен. Детали упускают.
Скажите, а отсюда версия не подошла?
Просто ставить Ubuntu на виртуалке только ради того, чтобы погонять Redis…
Кстати, «фичи» Redis я в коде не увидел, только простейший get set, для этого подойдет и memcached, и любое другое хранилище.
Что-то Вы перемудрили, мне кажется.
Просто ставить Ubuntu на виртуалке только ради того, чтобы погонять Redis…
Кстати, «фичи» Redis я в коде не увидел, только простейший get set, для этого подойдет и memcached, и любое другое хранилище.
Что-то Вы перемудрили, мне кажется.
Ту версию не пробовал. Поставить Ubuntu на виртуалку не проблема, делов минут на 5.
Мне хватило get,set для того что было нужно. в Lock верси правда используется SETNX, но не думаю что это основная фича Redis :)
Можно сделать и на memcached, но разве Redis не самый скоростной? К тому же он и на диск пишет, но тогда можно было бы взять membase или еще что-то. В общем выбор большой, и я выбрал Redis.
Насчет перемудрил, тут пусть каждый сам судит :)
Мне хватило get,set для того что было нужно. в Lock верси правда используется SETNX, но не думаю что это основная фича Redis :)
Можно сделать и на memcached, но разве Redis не самый скоростной? К тому же он и на диск пишет, но тогда можно было бы взять membase или еще что-то. В общем выбор большой, и я выбрал Redis.
Насчет перемудрил, тут пусть каждый сам судит :)
не очень понятно, почему стандартный StateServer из ASP.NET не подошел. можно по-подробнее?
Sign up to leave a comment.
Написание своего Session Store Provider ASP.NET использующего Redis