The video demos Chrome’s built in accessibility audit tool.
After watching the video I decided to run the tool against this site.
There were a few things I needed to fix to get this site to pass the audit. One of those things was the color contrast of the syntax highlighting I use for code snippets.
In this post I’ll explore that problem and talk about my approach to solving it.
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.
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.
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.