Today, I posted the following into my company’s HipChat…
[3:41 PM] Me:
$ curl 127.0.0.1:9000/status
curl: (56) Failure when receiving data from the peer
Is this supposed to work?
I quickly learned that no, it is not supposed to work…
[3:41 PM] Coworker:
no it doesn’t use http
Here I’ll go into details on how you can get the PHP-FPM status from the command line.
Warning: This article is highly critical of some blog posts, Stack Exchange answers, and GitHub issue comments. This is not a personal attack on the authors of those posts or answers. Instead, the intent is to call out the issues with some information that is floating around and provide alternate solutions to mitigate the risk of many users adopting practices that are harmful to the usage of the page cache in Magento 2.
Recently I wrote a post titled “How Magento 2 Decides If A Page Is Cacheable”. After I posted it on Twitter I got a response about the depersonalizer
... And don't forget about the depersonaliser: https://t.co/nqile0R5ny— Giel Berkers (@kanduvisla) October 22, 2017
I read through the article and felt a twinge of horror when I read this line…
BEWARE OF WHAT YOU ARE DOING HERE! Because basically you are disabling full-page cache entirely for every logged in customer
The author of the article was providing a “solution” that involved breaking full page cache for any logged in user.
I started doing some more research about what the author was writing about and over the course of that, learned that there is a lot of bad information floating around the internet about working with the Magento 2 page cache.
In this post, I’d like to help offer some best practices…
A high page cache hit rate is one of the most important factors in having a performant Magento 2 site. Unfortunately, it’s very easy to screw up.
In this post I’ll go into the Magento internals to demonstrate how Magento decides whether or not to cache a response. This is useful to know to help debug in cases where a site is not getting the most bang for buck out of the page cache.
It’s more or less universally accepted as best practice to ignore “vendor” code from your project’s source control.
For example, in the Ruby world, dependencies are referenced in a
Gemfile and are then installed entirely outside of the project directory.
package.json. They then get installed in the
node_modules directory within the project. However, that’s more or less universally ignored, as we can see for example in the
.gitignore file of the popular NodeJS framework, Express.
Go takes a similar approach to Ruby, installing dependencies in the
src/ folder of your
$GOPATH, outside of the project directory.
I primarily work with the Magento platform where ignoring vendor code is a relatively new concept, with the advent of Magento 2. Previously, code was installed into the
app/code directory in the
community code pool which typically was committed (although not by all).
While ignoring vendor code is by and large a good thing, there are a few things that you lose out on in doing so. Here I’ll outline the issues I’ve run into.
Per the docs…
MONITOR is a debugging command that streams back every command processed by the Redis server
When you envoke
wget with the
-r flag it will attempt to clone an entire website…a handy feature. However, by default you can end up with some pages being overwritten by directories.
Here, we’ll investigate the problem in more detail and lay out a solution.