Blog
Magento and New Relic Error Rate
Published: November 13, 2017
New Relic’s Error rate monitoring and alerting feature is a great way to catch unforeseen issues in production. However, properly using the feature requires an understanding of what is actually being measured.
In this post, we’ll take a look at what what New Relic’s “Error Rate” means for Magento applications.
Magento Config Cache Stampeding Race Condition
Published: October 30, 2017
It started with an alert.
CPU usage had climbed to above 80% on the web servers. Additionally, average response time had spiked.
In New Relic APM Pro, we could see in some slow transaction traces that the server was busy loading XML configurations…which should’ve been coming from cache.
After a few hours of investigation, we found that the issue was due to a core bug which can result in cache stampeding due to a race condition when the site is under high load.
Let’s dive into the issue.
Getting The PHP-FPM Status From The Command Line
Published: October 24, 2017
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 peerIs 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.
Working With The Magento 2 Page Cache The Right Way
Published: October 23, 2017
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…
How Magento 2 Decides If A Page Is Cacheable
Published: October 20, 2017
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.
I can safely say I've seen issues with cacheable="false" in every store with #Varnish I worked on, mostly in 3rd party extensions.#Magento2 pic.twitter.com/cHoOuFOSlp
— Miguel Balparda (@mbalparda) August 16, 2017
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.
What You Lose When You Ignore Vendor Code
Published: October 13, 2017
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.
In the JavaScript world, they’re declared in 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 local or 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.