<p><strong>Update:</strong></p>

<p>Am I allowed to change my mind on this? :)</p>

<p>My original answer didn't take into account <code>storage/logo</code>, <code>storage/backups</code> and anything else that a plugin might be storing in the <code>craft/storage</code> folder.</p>

<p>So it's probably going to be much cleaner and safer to have <code>CRAFT_STORAGE_PATH</code> point to the shared file system.</p>

<hr>

<ol>
<li><p>I would set <code>CRAFT_STORAGE_PATH</code> and have them write to their local file systems.  That way you have independent logs for each web server.</p></li>
<li><p>With that set to 'true', the PHP session files will go to whether PHP/nginx are configured to send them.</p></li>
<li><p>The <a href="http://buildwithcraft.com/docs/config-settings#cacheMethod" rel="nofollow noreferrer">cacheMethod</a> config setting it purely for data caching. It's set to 'file' by default which will write to <code>craft/storage/runtime/cache</code>, but you can change that to some other caching method.</p></li>
</ol>

<p>Actually, if you do #1, then 2 and 3 would resolve themselves, no? You'd want to make sure that your load balancer has stick sessions enabled so that a user would get sent to the same web server for subsequent requests.</p>

CC BY-SA 3.0
2014-11-13T23:52:23.417Z
Thank Brad.  After moving CRAFT_STORAGE_PATH, Should I keep storage/userphotos on the shared fs i.e. using a symbolic link, or does a variable exists that can override its location?
Mathieu P.
CC BY-SA 3.0
2014-11-13T23:55:26.497Z
No variable current exists for that, so you'd probably need to symlink it.
Brad Bell
CC BY-SA 3.0
2015-01-22T22:44:59.580Z
Hi Brad, I ended up leaving CRAFT_STORAGE_PATH to the shared file system but moved / sym-liked the "runtime" sub-folder to a node local partition.  This leaves all other storage sub-folders, i.e. backups, userphotos, logo and any plugin created folders on the shared file system.  So far so good.
Mathieu P.
CC BY-SA 3.0
2017-01-11T16:32:34.370Z
A bit confused by @BradBell's answer...I'm not seeing `CRAFT_STORAGE_RUNTIME` as defined constant at all. _"So it's probably going to be much cleaner and safer to have `CRAFT_STORAGE_RUNTIME` point to the shared file system."_ seems to contradict with _"I would set `CRAFT_STORAGE_PATH` and have them write to their local file systems. That way you have independent logs for each web server."_
Tim Kelty
CC BY-SA 3.0
2017-01-11T23:20:39.197Z
@TimKelty Sorry, typo.  Should have been `CRAFT_STORAGE_PATH`.
Brad Bell
CC BY-SA 3.0
2017-01-12T13:12:55.557Z
@BradBell Ok, then which are you recommending (seems like you say both) `CRAFT_STORAGE_PATH` shared or independent?
Tim Kelty
CC BY-SA 3.0
2017-01-12T22:36:32.900Z
@TimKelty Everything above the `<hr>` is my updated answer. `CRAFT_STORAGE_PATH` shared.
Brad Bell
CC BY-SA 3.0
2017-01-16T13:43:00.687Z
@BradBell OK, so with that setup, you wouldn't be able to have separate logs per-server though, right? Currently I have `CRAFT_STORAGE_PATH` shared between servers, but then `CRAFT_STORAGE_PATH`/runtime per-server (via relative symlink).
Tim Kelty
CC BY-SA 3.0
2017-01-17T14:54:41.357Z
So I've found if I dedicate the runtime folder per-server, I end up with session/login trouble. Logins fail about 50% of the time (go figure, we have a 2 server LB). By "fail" I mean the cp login simply reloads on submit, no error.

Once the login succeeds, sticky sessions are working fine, and the user stays logged in.

If I make the runtime folder shared between servers, logins work fine, but we now don't have server-specific logs.
Tim Kelty
CC BY-SA 3.0
2017-05-27T15:24:08.057Z
@TimKelty FWIW we had the dicey-login trouble on a load-balanced project and got around it by using Craft's `overridePhpSessionLocation` and pointing to a Redis (RDS) store instead.
Matt Stein
CC BY-SA 4.0
2023-03-06T14:26:49.520Z
@BradBell Is NFS share a requirement for Craft4 too? Based on documents, it looks like we can skip it. Not sure what would be impact on application.
dhumketu
CC BY-SA 4.0
2023-03-06T21:11:22.210Z
@binarymemoir Not necessarily NFS, but _a_ shared storage solution solves many problems in a load-balanced environment. See: https://craftcms.com/knowledge-base/configuring-load-balanced-environments
Brad Bell
CC BY-SA 3.0
2014-11-13T23:34:17.653Z
2017-01-11T23:20:09.367Z
2017-01-11T23:20:09.367Z
Brad Bell
<p>Craft deployed and working well on one node.  Now looking into load balancing 3 nodes behind a LTM device (F5 Big-IP).  The server environment is the following:</p>

<ul>
<li>a GlusterFS replicated "shared" file-system mounted on the 3 nodes</li>
<li>Craft app is installed in the <strong>shared</strong> file-system (so is the webroot and all common files, but Craft itself is outside of the webroot).</li>
<li>a replicated MySQL database cluster hosting the Craft database (Percona xtraDB Cluster)</li>
<li>Each node is configured with PHP ZendOpcache and Nginx.</li>
</ul>

<p>Currently, Craft Vhost is enabled only on one node because I have the following questions:</p>

<ol>
<li>What should I do with the "storage" folder.  Currently, it's on the shared file-system, so all the node share the same folder, is this an issue, i.e. should I move it to a local file system and set CRAFT_STORAGE_PATH accordingly?</li>
<li>overridePhpSessionLocation: I set to true (so it does not write to 'storage/runtime/sessions'</li>
<li>CacheMethod, is this for OPcaching or user data caching?  (Currently ZendOpcache is configured at the PHP level, but I still see entries in the storage/runtime/cache folder)</li>
</ol>

<p>Any pitfalls I should be aware or specific configuration needed for a load-balanced set of Craft instances?</p>

<p>Thanks.</p>

<config><install><performance>
Load balancing nodes configuration (3 Craft nodes behind F5 Big-IP)
# Load balancing nodes configuration (3 Craft nodes behind F5 Big-IP)

(Asked by: username_0 on 2014-11-13)

Craft deployed and working well on one node. Now looking into load balancing 3 nodes behind a LTM device (F5 Big-IP). The server environment is the following:

* a GlusterFS replicated "shared" file-system mounted on the 3 nodes
* Craft app is installed in the **shared** file-system (so is the webroot and all common files, but Craft itself is outside of the webroot).
* a replicated MySQL database cluster hosting the Craft database (Percona xtraDB Cluster)
* Each node is configured with PHP ZendOpcache and Nginx.

Currently, Craft Vhost is enabled only on one node because I have the following questions:

1. What should I do with the "storage" folder. Currently, it's on the shared file-system, so all the node share the same folder, is this an issue, i.e. should I move it to a local file system and set CRAFT\_STORAGE\_PATH accordingly?
2. overridePhpSessionLocation: I set to true (so it does not write to 'storage/runtime/sessions'
3. CacheMethod, is this for OPcaching or user data caching? (Currently ZendOpcache is configured at the PHP level, but I still see entries in the storage/runtime/cache folder)

Any pitfalls I should be aware or specific configuration needed for a load-balanced set of Craft instances?

Thanks.

**Tags:** config, install, performance

---

## 1 answers

### Answer by username_1 on 2014-11-13. Score: 5

**Update:**

Am I allowed to change my mind on this? :)

My original answer didn't take into account `storage/logo`, `storage/backups` and anything else that a plugin might be storing in the `craft/storage` folder.

So it's probably going to be much cleaner and safer to have `CRAFT_STORAGE_PATH` point to the shared file system.

---

1. I would set `CRAFT_STORAGE_PATH` and have them write to their local file systems. That way you have independent logs for each web server.
2. With that set to 'true', the PHP session files will go to whether PHP/nginx are configured to send them.
3. The [cacheMethod](http://buildwithcraft.com/docs/config-settings#cacheMethod) config setting it purely for data caching. It's set to 'file' by default which will write to `craft/storage/runtime/cache`, but you can change that to some other caching method.

Actually, if you do #1, then 2 and 3 would resolve themselves, no? You'd want to make sure that your load balancer has stick sessions enabled so that a user would get sent to the same web server for subsequent requests.

> **Comments:**
> **username_0**: Thank Brad.  After moving CRAFT_STORAGE_PATH, Should I keep storage/userphotos on the shared fs i.e. using a symbolic link, or does a variable exists that can override its location?  
> **username_1**: No variable current exists for that, so you'd probably need to symlink it.  
> **username_0**: Hi Brad, I ended up leaving CRAFT_STORAGE_PATH to the shared file system but moved / sym-liked the "runtime" sub-folder to a node local partition.  This leaves all other storage sub-folders, i.e. backups, userphotos, logo and any plugin created folders on the shared file system.  So far so good.  
> **username_2**: A bit confused by @BradBell's answer...I'm not seeing `CRAFT_STORAGE_RUNTIME` as defined constant at all. _"So it's probably going to be much cleaner and safer to have `CRAFT_STORAGE_RUNTIME` point to the shared file system."_ seems to contradict with _"I would set `CRAFT_STORAGE_PATH` and have them write to their local file systems. That way you have independent logs for each web server."_  
> **username_1**: @TimKelty Sorry, typo.  Should have been `CRAFT_STORAGE_PATH`.  
> **username_2**: @BradBell Ok, then which are you recommending (seems like you say both) `CRAFT_STORAGE_PATH` shared or independent?  
> **username_1**: @TimKelty Everything above the `<hr>` is my updated answer. `CRAFT_STORAGE_PATH` shared.  
> **username_2**: @BradBell OK, so with that setup, you wouldn't be able to have separate logs per-server though, right? Currently I have `CRAFT_STORAGE_PATH` shared between servers, but then `CRAFT_STORAGE_PATH`/runtime per-server (via relative symlink).  
> **username_2**: So I've found if I dedicate the runtime folder per-server, I end up with session/login trouble. Logins fail about 50% of the time (go figure, we have a 2 server LB). By "fail" I mean the cp login simply reloads on submit, no error.  Once the login succeeds, sticky sessions are working fine, and the user stays logged in.  If I make the runtime folder shared between servers, logins work fine, but we now don't have server-specific logs.  
> **username_3**: @TimKelty FWIW we had the dicey-login trouble on a load-balanced project and got around it by using Craft's `overridePhpSessionLocation` and pointing to a Redis (RDS) store instead.  
> **username_4**: @BradBell Is NFS share a requirement for Craft4 too? Based on documents, it looks like we can skip it. Not sure what would be impact on application.  
> **username_1**: @binarymemoir Not necessarily NFS, but _a_ shared storage solution solves many problems in a load-balanced environment. See: https://craftcms.com/knowledge-base/configuring-load-balanced-environments  

---

