The Magento cron has a nasty habit of getting stuck. Ideally this wouldn’t happen, but it’s a fact of life.
Ultimately, if you have a site where cron is getting stuck frequently you’re going to want to spend some time diagnosing the root cause. That being said, in all cases, it’s probably a good idea to have something in place that will tell you if and when the Magento cron gets stuck…even on sites where it has never happened to you before.
We’ve implemented a good system for doing this at Something Digital. We’re using two tools from the “TICK” stack - InfluxDb, a time-series database which we use to store data from
cron_schedule, and Kapacitor, an agent that runs alongside InfluxDb and can stream or batch query data and react to it (e.g. send alerts). In this post I’ll outline our set up.
NOTE: Magento 2 has significantly improved reliability of cron through new features such as groups (which are actually available in Magento 1 if you use
Aoe_Scheduler) and the ability to parallelize jobs with the
use_separate_processsetting. That being said, cron is always mission critical and there’s never a case where you shouldn’t be monitoring it.
We’ve been breaking some new ground (at least from what I can see in my Google searches) at Something Digital with the work we’ve been doing to monitor, and improve, FPC hit rate using
Enterprise_PageCache on our client’s sites. I’ll likely publish a few posts related to this topic, but the first thing I wanted to focus on is why, and how, you can track your FPC hit rate.
Working at a Magento consultancy, I have the privilege of interacting with a plethora of merchants that run their businesses on Magento. One aspect of this that never gets old is all the things merchants think should function differently than how Magento thinks they should function. Here is just a short list of things I’ve encountered…
The list above falls into the category of things that can more or less be safely customized. However, sometimes there are things that you just shouldn’t customize.
Recently, we onboarded a client whose site had customized a couple of those things. In this post I’ll outline these examples and demonstrate unintended consequences of trying to make Magento behave differently than it was meant to.
<script> tags. Some might say they power the internet.
There are all different kinds of marketing
<script> tags. There are simple ones that you just embed in the global footer and are done with. Then, there are complex ones that fire when a user “converts” and ask you to send back the total order amount, a list of products, tax and shipping costs and the user’s mother’s maiden name.
Adding and removing these tags is such a common task for any website that there are entire platforms (see: Google Tag Manager) created just for the point of doing so. They introduce a new knowledge domain and buzzwords like data layer.
That’s all fine and dandy, but what happens when they don’t work? Below is a story where a marketing pixel caused a big problem, and a proposal for how we can help makes these backbones of the internet a little less dangerous.
I first heard about Prometheus on an episode of The Changelog Podcast. Before tuning in, I read the description and was intrigued. Monitoring is an important part of my day job where my team is responsible for ensuring the technical end of operations runs smoothly for many large scale ecommerce businesses. I saw that the episode featured an engineer from SoundCloud (a service I use regularly for streaming music) and decided to give it a spin.
In my work at Something Digital I’ve recently taken a deep dive into profiling and improving performance, at scale, of the search results page (
/catalogsearch/result/index). In our case, we have a client whose traffic profile is very search heavy, and ran into performance issues due to a traffic sure to that route. The investigation was very interesting, and I thought it would be beneficial to document some of the key findings here.