Hot answers tagged cache
Yes, if it has enough RAM, the file system of Linux will cache these files. All other layers rely on the FS cache. There might be higher levels of caching that caches the generated output of the site, but this has to be specifically configured with an appropriate module like APC.
The OS has filesystem cache, which caches read / write requests to the actual hardware device. Then to the specific questions: Apache doesn't do caching. The include() functions don't do caching in default PHP installations. If you install an OPCode cache like APC, Xcache or OPCache, then it will cache compiled versions of the code in memory. File system ...
Don't reinvent the wheel. Use ZFS. But you have other architectural concerns like networking, tuning, your client systems. It may also be helpful to describe the context for this and what you currently have in place.
This seems to be an old bug, explaining why Header unset ETag makes a difference. Apache 2.4.0+ automatically appends the compression method name to the ETag (as seen in your headers), and prevents a 304 response. Newest versions of mod_deflate support a DeflateAlterETag that can be used to control this behavior: DeflateAlterETag NoChange
Can someone explain OPcache memory usage in layman terms ? ldennison plus the various commenters have probably/mostly answered this part. Another great write-up can be found here: http://www.sitepoint.com/understanding-opcache/ Allow me to summarise: OPcache allows you to pre-allocate a certain amount of memory. You have set it to 1024, ie. 1GB. ...
The curl client isn't caching files, but the remote server network might well be. Try adding an arbitrary query string variable to the URL to see if you can reproduce it.
Your opcache memory limit (currently set to 1024MB/1GB by the looks of it) should be large enough to cover the size of all the PHP files being cached by Opcache. 1GB for a set of PHP files is large, so that may not be the issue, but you should at least start there. The "File Usage" button on your attached screenshot likely will give you a report of memory ...
Although ZFS can do it, like ewwhite says, another solution might be bcache. I'm using that in a totally different scenario (2TB HDD and 128GB SSD in my laptop, using bcache makes loading Civ V a lot nicer ;-)), but it works very nicely. Depending on how you serve the files, you might also want to consider something like Varnish, which you setup to use the ...
Your concern is correct - clients whose browsers have retrieved the file will typically not receive the updated version until 1 month after they accessed it unless they happen to have cleared their browser cache or they do a reload on the page. One way around this is when you update the CSS file, change the HTML that references it to have ?v=2 or ?v=3 ...
When you hit F5 in a browser, you are instructing the browser to ask the sever and any proxies in the path for new content. That Cache-Control request header does just that. It does not get added during normal navigation. Also, PHP has no way of knowing that your content didn't change, especially if it is making a database call. It will never return a 304 ...
Do not do this. I repeat: Do not do this! You will get cluster headaches out of this. If metadata changes in meantime, it could cause crashes and/or invalid data returned. These filesystems are not designed to work like this. Do not use them that way. This is especially bad idea with ZFS. If you really have to, use something very very basic, without ...
Only top voted, non community-wiki answers of a minimum length are eligible