<p>I can't say for certain if you would see faster session handling if you added the overridePhpSessionLocation config key, but have you added the <a href="https://craftcms.com/docs/config-settings#appId" rel="nofollow noreferrer">appId</a> and <a href="https://craftcms.com/docs/config-settings#validationKey" rel="nofollow noreferrer">validationKey</a> configuration keys? I was recently having issues in my load balanced environments because these keys were not set.</p>

CC BY-SA 3.0
2016-11-17T21:19:45.810Z
I have an appId in my General.php but not a validationKey. It looks like craft automatically generates one though, would this possibly fix it? It's weird because when we attempt to make several updates to the same session variable very quickly they get out of sync for some reason.
Exziled
CC BY-SA 3.0
2016-11-17T21:27:29.827Z
I'm admittedly not an expert on this, but i imagine it could cause issues if the validation key isn't the same for every server in the cluster. Especially if data from those servers is all coming back to a centralized Redis box.
Leah Scott
CC BY-SA 3.0
2016-11-17T21:29:44.883Z
Based on that last comment though you might also wanna comb through your sessions work flow for any race conditions.
Leah Scott
CC BY-SA 3.0
2016-11-17T21:03:24.860Z
2016-11-17T21:03:24.860Z
Leah Scott
<p>We've recently set up a Redis cluster to handle our PHP sessions since we use a load balancer to direct traffic into different craft instances.</p>

<p>We're seeing issues with redis when making back to back PHP session calls (using craft wrapper) very quickly. If we update a variable in the httpSession and then try to update it/get it very quickly it isn't updating. If we wait to access it then it is updated correctly.</p>

<p>How it's set up:
We modified the Apache2 php.ini to update the session handler to redis and the save path to our redis cluster (bypassing doing this via Craft). So Craft still uses its' default session handling but when it makes the request to save the session it gets redirected by apache to our redis.</p>

<p>Is it more beneficial to tie this to Craft by updating the General.php with the session override options? Will we see faster/better session handling? Is there a session lock happening in craft? Is Craft opening/closing the session after each httpSessionService call?</p>

<config><session><redis>
Craft with Redis session handling
# Craft with Redis session handling

(Asked by: username_0 on 2016-11-17)

We've recently set up a Redis cluster to handle our PHP sessions since we use a load balancer to direct traffic into different craft instances.

We're seeing issues with redis when making back to back PHP session calls (using craft wrapper) very quickly. If we update a variable in the httpSession and then try to update it/get it very quickly it isn't updating. If we wait to access it then it is updated correctly.

How it's set up:
We modified the Apache2 php.ini to update the session handler to redis and the save path to our redis cluster (bypassing doing this via Craft). So Craft still uses its' default session handling but when it makes the request to save the session it gets redirected by apache to our redis.

Is it more beneficial to tie this to Craft by updating the General.php with the session override options? Will we see faster/better session handling? Is there a session lock happening in craft? Is Craft opening/closing the session after each httpSessionService call?

**Tags:** config, session, redis


---

## 1 answers

### Answer by username_1 on 2016-11-17. Score: 1

I can't say for certain if you would see faster session handling if you added the overridePhpSessionLocation config key, but have you added the [appId](https://craftcms.com/docs/config-settings#appId) and [validationKey](https://craftcms.com/docs/config-settings#validationKey) configuration keys? I was recently having issues in my load balanced environments because these keys were not set.

> **Comments:**
> **username_0**: I have an appId in my General.php but not a validationKey. It looks like craft automatically generates one though, would this possibly fix it? It's weird because when we attempt to make several updates to the same session variable very quickly they get out of sync for some reason.  
> **username_1**: I'm admittedly not an expert on this, but i imagine it could cause issues if the validation key isn't the same for every server in the cluster. Especially if data from those servers is all coming back to a centralized Redis box.  
> **username_1**: Based on that last comment though you might also wanna comb through your sessions work flow for any race conditions.  

---

