Azure redis cache, is it necessary?
Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
Currenty we are running Sitecore 9.0 on Azure Paas. I would like to know which is the purpose of the Azure Redis Cache?
Reading some documentation it seems that it´s to store session properties of users. We are an e-commerce site, but we are using a custom mechanism for the users session, not using the one provided by Sitecore. If we are not using it, is it necessary to have the Redis Cache?
We have looked at redis, it contains a hundred of keys, with not readable content for us. In some blogs I read that the Redis Cache it´s useful decreasing response time in requests peaks. But I´m not sure if it´s useful when we are not using Session mechanism from Sitecore.
Thanks
azure paas redis
add a comment |
up vote
3
down vote
favorite
Currenty we are running Sitecore 9.0 on Azure Paas. I would like to know which is the purpose of the Azure Redis Cache?
Reading some documentation it seems that it´s to store session properties of users. We are an e-commerce site, but we are using a custom mechanism for the users session, not using the one provided by Sitecore. If we are not using it, is it necessary to have the Redis Cache?
We have looked at redis, it contains a hundred of keys, with not readable content for us. In some blogs I read that the Redis Cache it´s useful decreasing response time in requests peaks. But I´m not sure if it´s useful when we are not using Session mechanism from Sitecore.
Thanks
azure paas redis
add a comment |
up vote
3
down vote
favorite
up vote
3
down vote
favorite
Currenty we are running Sitecore 9.0 on Azure Paas. I would like to know which is the purpose of the Azure Redis Cache?
Reading some documentation it seems that it´s to store session properties of users. We are an e-commerce site, but we are using a custom mechanism for the users session, not using the one provided by Sitecore. If we are not using it, is it necessary to have the Redis Cache?
We have looked at redis, it contains a hundred of keys, with not readable content for us. In some blogs I read that the Redis Cache it´s useful decreasing response time in requests peaks. But I´m not sure if it´s useful when we are not using Session mechanism from Sitecore.
Thanks
azure paas redis
Currenty we are running Sitecore 9.0 on Azure Paas. I would like to know which is the purpose of the Azure Redis Cache?
Reading some documentation it seems that it´s to store session properties of users. We are an e-commerce site, but we are using a custom mechanism for the users session, not using the one provided by Sitecore. If we are not using it, is it necessary to have the Redis Cache?
We have looked at redis, it contains a hundred of keys, with not readable content for us. In some blogs I read that the Redis Cache it´s useful decreasing response time in requests peaks. But I´m not sure if it´s useful when we are not using Session mechanism from Sitecore.
Thanks
azure paas redis
azure paas redis
edited Nov 19 at 8:27
Tamas Varga Sitecore
2,5661953
2,5661953
asked Nov 19 at 8:10
Marc Cals
1905
1905
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
8
down vote
accepted
Azure Redis cache is the default session provider Sitecore 9.0 will use in Azure Paas. Out of the box, Azure Redis Cache will be configured and used by Sitecore.
Sitecore uses this session provider as a means of managing out of process (ie. distributed) session state to share contact data across browser sessions and devices. This is required to support base functionality in Sitecore XP (Analytics, XDB etc). Even if you are using a custom session provider for other purposes, you will likely still need the Sitecore sessions configured to get full value out of the solution. You can find some more information on how Sitecore manages session data here:
https://doc.sitecore.net/sitecore_experience_platform/setting_up_and_maintaining/session_state/session_state/session_state
Redis is designed as a means for fast, distributed access to a key/value store. If you're digging into the redis instance directly, you're likely to see all of the keys of your current sessions (private and shared) with non-readable values (usually stored as binary vals). These values are usually managed and accessed via the Sitecore Session API abstractions. It's rare you would need to access Redis directly.
Sitecore 9.0 supports Redis and SQL Server as distributed session providers. So, no, Redis is not required...however a session state provider is required for Sitecore XP. ie. You need Redis OR SQL Server configured. Which you select really depends on your exact situation. If required, details on how to configure the SQL provider as an alternative is documented here:
https://doc.sitecore.net/sitecore_experience_platform/setting_up_and_maintaining/session_state/session_state/walkthrough_configuring_a_private_session_state_database_using_the_sql_server_provider
Thanks @GWDT for your answer. If we don´t use Services like Analytics, XDB. Is it still recommended to have the session mechanism of Sitecore enabled?
– Marc Cals
Nov 19 at 9:32
1
Yes. Sessions are still recommended even using the XM (No analytics or marketing features) topologies. You can find out more on the 9.0 arch options here: doc.sitecore.net/sitecore_experience_platform/…
– GWDT
Nov 19 at 9:43
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
8
down vote
accepted
Azure Redis cache is the default session provider Sitecore 9.0 will use in Azure Paas. Out of the box, Azure Redis Cache will be configured and used by Sitecore.
Sitecore uses this session provider as a means of managing out of process (ie. distributed) session state to share contact data across browser sessions and devices. This is required to support base functionality in Sitecore XP (Analytics, XDB etc). Even if you are using a custom session provider for other purposes, you will likely still need the Sitecore sessions configured to get full value out of the solution. You can find some more information on how Sitecore manages session data here:
https://doc.sitecore.net/sitecore_experience_platform/setting_up_and_maintaining/session_state/session_state/session_state
Redis is designed as a means for fast, distributed access to a key/value store. If you're digging into the redis instance directly, you're likely to see all of the keys of your current sessions (private and shared) with non-readable values (usually stored as binary vals). These values are usually managed and accessed via the Sitecore Session API abstractions. It's rare you would need to access Redis directly.
Sitecore 9.0 supports Redis and SQL Server as distributed session providers. So, no, Redis is not required...however a session state provider is required for Sitecore XP. ie. You need Redis OR SQL Server configured. Which you select really depends on your exact situation. If required, details on how to configure the SQL provider as an alternative is documented here:
https://doc.sitecore.net/sitecore_experience_platform/setting_up_and_maintaining/session_state/session_state/walkthrough_configuring_a_private_session_state_database_using_the_sql_server_provider
Thanks @GWDT for your answer. If we don´t use Services like Analytics, XDB. Is it still recommended to have the session mechanism of Sitecore enabled?
– Marc Cals
Nov 19 at 9:32
1
Yes. Sessions are still recommended even using the XM (No analytics or marketing features) topologies. You can find out more on the 9.0 arch options here: doc.sitecore.net/sitecore_experience_platform/…
– GWDT
Nov 19 at 9:43
add a comment |
up vote
8
down vote
accepted
Azure Redis cache is the default session provider Sitecore 9.0 will use in Azure Paas. Out of the box, Azure Redis Cache will be configured and used by Sitecore.
Sitecore uses this session provider as a means of managing out of process (ie. distributed) session state to share contact data across browser sessions and devices. This is required to support base functionality in Sitecore XP (Analytics, XDB etc). Even if you are using a custom session provider for other purposes, you will likely still need the Sitecore sessions configured to get full value out of the solution. You can find some more information on how Sitecore manages session data here:
https://doc.sitecore.net/sitecore_experience_platform/setting_up_and_maintaining/session_state/session_state/session_state
Redis is designed as a means for fast, distributed access to a key/value store. If you're digging into the redis instance directly, you're likely to see all of the keys of your current sessions (private and shared) with non-readable values (usually stored as binary vals). These values are usually managed and accessed via the Sitecore Session API abstractions. It's rare you would need to access Redis directly.
Sitecore 9.0 supports Redis and SQL Server as distributed session providers. So, no, Redis is not required...however a session state provider is required for Sitecore XP. ie. You need Redis OR SQL Server configured. Which you select really depends on your exact situation. If required, details on how to configure the SQL provider as an alternative is documented here:
https://doc.sitecore.net/sitecore_experience_platform/setting_up_and_maintaining/session_state/session_state/walkthrough_configuring_a_private_session_state_database_using_the_sql_server_provider
Thanks @GWDT for your answer. If we don´t use Services like Analytics, XDB. Is it still recommended to have the session mechanism of Sitecore enabled?
– Marc Cals
Nov 19 at 9:32
1
Yes. Sessions are still recommended even using the XM (No analytics or marketing features) topologies. You can find out more on the 9.0 arch options here: doc.sitecore.net/sitecore_experience_platform/…
– GWDT
Nov 19 at 9:43
add a comment |
up vote
8
down vote
accepted
up vote
8
down vote
accepted
Azure Redis cache is the default session provider Sitecore 9.0 will use in Azure Paas. Out of the box, Azure Redis Cache will be configured and used by Sitecore.
Sitecore uses this session provider as a means of managing out of process (ie. distributed) session state to share contact data across browser sessions and devices. This is required to support base functionality in Sitecore XP (Analytics, XDB etc). Even if you are using a custom session provider for other purposes, you will likely still need the Sitecore sessions configured to get full value out of the solution. You can find some more information on how Sitecore manages session data here:
https://doc.sitecore.net/sitecore_experience_platform/setting_up_and_maintaining/session_state/session_state/session_state
Redis is designed as a means for fast, distributed access to a key/value store. If you're digging into the redis instance directly, you're likely to see all of the keys of your current sessions (private and shared) with non-readable values (usually stored as binary vals). These values are usually managed and accessed via the Sitecore Session API abstractions. It's rare you would need to access Redis directly.
Sitecore 9.0 supports Redis and SQL Server as distributed session providers. So, no, Redis is not required...however a session state provider is required for Sitecore XP. ie. You need Redis OR SQL Server configured. Which you select really depends on your exact situation. If required, details on how to configure the SQL provider as an alternative is documented here:
https://doc.sitecore.net/sitecore_experience_platform/setting_up_and_maintaining/session_state/session_state/walkthrough_configuring_a_private_session_state_database_using_the_sql_server_provider
Azure Redis cache is the default session provider Sitecore 9.0 will use in Azure Paas. Out of the box, Azure Redis Cache will be configured and used by Sitecore.
Sitecore uses this session provider as a means of managing out of process (ie. distributed) session state to share contact data across browser sessions and devices. This is required to support base functionality in Sitecore XP (Analytics, XDB etc). Even if you are using a custom session provider for other purposes, you will likely still need the Sitecore sessions configured to get full value out of the solution. You can find some more information on how Sitecore manages session data here:
https://doc.sitecore.net/sitecore_experience_platform/setting_up_and_maintaining/session_state/session_state/session_state
Redis is designed as a means for fast, distributed access to a key/value store. If you're digging into the redis instance directly, you're likely to see all of the keys of your current sessions (private and shared) with non-readable values (usually stored as binary vals). These values are usually managed and accessed via the Sitecore Session API abstractions. It's rare you would need to access Redis directly.
Sitecore 9.0 supports Redis and SQL Server as distributed session providers. So, no, Redis is not required...however a session state provider is required for Sitecore XP. ie. You need Redis OR SQL Server configured. Which you select really depends on your exact situation. If required, details on how to configure the SQL provider as an alternative is documented here:
https://doc.sitecore.net/sitecore_experience_platform/setting_up_and_maintaining/session_state/session_state/walkthrough_configuring_a_private_session_state_database_using_the_sql_server_provider
answered Nov 19 at 9:05
GWDT
1365
1365
Thanks @GWDT for your answer. If we don´t use Services like Analytics, XDB. Is it still recommended to have the session mechanism of Sitecore enabled?
– Marc Cals
Nov 19 at 9:32
1
Yes. Sessions are still recommended even using the XM (No analytics or marketing features) topologies. You can find out more on the 9.0 arch options here: doc.sitecore.net/sitecore_experience_platform/…
– GWDT
Nov 19 at 9:43
add a comment |
Thanks @GWDT for your answer. If we don´t use Services like Analytics, XDB. Is it still recommended to have the session mechanism of Sitecore enabled?
– Marc Cals
Nov 19 at 9:32
1
Yes. Sessions are still recommended even using the XM (No analytics or marketing features) topologies. You can find out more on the 9.0 arch options here: doc.sitecore.net/sitecore_experience_platform/…
– GWDT
Nov 19 at 9:43
Thanks @GWDT for your answer. If we don´t use Services like Analytics, XDB. Is it still recommended to have the session mechanism of Sitecore enabled?
– Marc Cals
Nov 19 at 9:32
Thanks @GWDT for your answer. If we don´t use Services like Analytics, XDB. Is it still recommended to have the session mechanism of Sitecore enabled?
– Marc Cals
Nov 19 at 9:32
1
1
Yes. Sessions are still recommended even using the XM (No analytics or marketing features) topologies. You can find out more on the 9.0 arch options here: doc.sitecore.net/sitecore_experience_platform/…
– GWDT
Nov 19 at 9:43
Yes. Sessions are still recommended even using the XM (No analytics or marketing features) topologies. You can find out more on the 9.0 arch options here: doc.sitecore.net/sitecore_experience_platform/…
– GWDT
Nov 19 at 9:43
add a comment |
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsitecore.stackexchange.com%2fquestions%2f15009%2fazure-redis-cache-is-it-necessary%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown