1

I currently have an application that is using the default view caching that is included with Laravel blade templating. As expected, when the blade files are compiled, the cached view is stored in storage/framework/views (this is the default Laravel value).

When working with my Techops team, they mentioned that these compiled views needed to be put onto an S3 server vs. stored on the local instance. I've found a possible way to overwrite this here, How do I disable Laravel view cache?. Which I have started to implement into my application.

My question is, what is the benefit of pushing these to an S3 server vs. local directory, if any? Will this method cause any latency in load times? Any other issues you may see arising with this method?

snft02
  • 11
  • 2

1 Answers1

0

Hope it's not too late for an answer but I can see two impacts (not necessarily negative ones) with this approach.

First is the cache utilisation rate going up (which is a good thing), specially if you have too many instances in a load balancer.

Let suppose you have a url, http://example.org/foo/bar, which generates a view and cache it locally. The cache will use it again only when the same server is hit. If another server is hit for this url, all the process of parsing and caching needs to be done.

If all instances points to a S3 bucket, once one instance caches it for the first time, it will be available for all other instances that won't need to reprocess everything again locally.

S3 has a higher latency time than a local disk, for sure, but you can speed it up with the proper configuration on bucket, and/or other resources (I would even bet on elastic cache with redis for this task instead of s3).

Another thing is the cost. S3 is way cheaper than EBS volumes to store data. So depending on how much data you are going to store, this can be in discussion too.

Davis Peixoto
  • 5,695
  • 2
  • 23
  • 35