Его провайдер мне не подходит, все равно писать свой, для параллельного доступа к записи в сессию (я этот момент отметил в статье).
Пробовал его. Так же написал похожий провайдер, который использует только его функции как кэша. С ним все работает, скорость по моим ощущениям у него хуже чем у решения с Redis, хотя конечно тестов не делал.
Но тем кому нужно в продакшен и важна стабильность однозначно сначала его попробовать, перед использованием других компонентов и тем более написания велосипедов типа моего :)
Просто интересно, мы просто даже обкатывать не рискнули, про него стока слухов ходит (да и не тока слухов, на прошлом PDC вторую ноду на глазах у всех подключить не смогли). Еще более будет интересно узнать результаты использования в продакшене.
Можете верить или не верить, но рекомендую все-таки проверить. В качестве теста можете сделать таблицу key-value с некластерным индексом, затолкать туда хотя бы пол миллиона записей, потом закинуть эти записи в AppFabric и вынимать. Для получения данных из Sql Server использовать BlToolkit (а то EF может сильно исказить результаты:)) или по страринке датаридером, для чистоты эксперимента. Результаты скажут сами за себя.
Скорее всего именно по этой причине ребята из StackOverflow не стали использовать у себя AppFabric в качестве кэша, а поставили сервер на Linux с Redis.
Только что проверил: на 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
1. Какой тип колонки Key в БД?
2. Есть некластерный индекс по Key include Value?
3. Свободной оперативной памяти достаточно? Это важно и для SQL и для AppFabric, он может просто выкинуть все из кэша, если решит, что мало памяти.
4. В настройках AppFabric указано не юзать локальный кэш?
5. Чтения должны выполняться по одним и тем же ключам, т.е. сначала надо сгенерить рандомные ключи, а потом по ним тащить значения.
6. И неплохо было бы сначала выполнить холостой прогон метода, а потом с замером в цикле. JIT.
1) см ниже
2) есть
3) Всего достаточно, там не так много данных
4) указано
5) да алдно, это непринципиально
6) jit тут — капля в море, ибо рассчетов нет
3. AppFabric выкидывает данные из кэша, если считает, что осталось мало памяти. Для теста это может быть важно:)
5. Даже спорить не буду:)
6. Ага, и DEBUG/RELEASE компиляция тоже пофигу.
Право не знаю что сказать… Наши тесты подтвердили то, что AppFabric сливает SQL Server'у, причем нормально так сливает. Это же подтвердил и Google — люди пишут о таких же результатах, какие получили мы. Как будет время, я сделаю еще раз тест и проверю ваш на моем компе.
1) это неважно, до nvarchar(400) колонка индексируется
2) Вот результаты с уник ключем + инклуд
Fill cache: 5431
Fill sql: 44759
Read cache: 6035
Read sql: 23743
3) А вот с локальным кешем
Fill cache: 4288
Fill sql: 37318
Read cache: 113
Read sql: 23277
Скажите, а отсюда версия не подошла?
Просто ставить Ubuntu на виртуалке только ради того, чтобы погонять Redis…
Кстати, «фичи» Redis я в коде не увидел, только простейший get set, для этого подойдет и memcached, и любое другое хранилище.
Что-то Вы перемудрили, мне кажется.
Ту версию не пробовал. Поставить Ubuntu на виртуалку не проблема, делов минут на 5.
Мне хватило get,set для того что было нужно. в Lock верси правда используется SETNX, но не думаю что это основная фича Redis :)
Можно сделать и на memcached, но разве Redis не самый скоростной? К тому же он и на диск пишет, но тогда можно было бы взять membase или еще что-то. В общем выбор большой, и я выбрал Redis.
Несколько причин
1. StateServer не сохраняет на диск (а для нас желательно)
2. Мне кажется Redis будет быстрее. Надо бы провести тесты.
3. Надеюсь они допилят кластер в Redis в обозримом будущем и это все еще сможет масштабироваться.
Написание своего Session Store Provider ASP.NET использующего Redis