I do a fair bit of performance oriented consulting/contracting work with Magento Agencies / Developers. A common theme seems to be difficulty monitoring/debugging Varnish. The Varnish Service Watching a specific URLs Age We can monitor how long a specific URL is staying in cache, by wrapping a curl command within a while loop. (Note: You may need to update your varnish config to stop removing the Age header) while true; do curl -Iso /dev/null -w '[%header{Date}] %{http_code} %{url} %header{x-cache} %header{age}\n' https://example.com && sleep 1; done Checking if you have allocated enough memory to Varnish We can use the varnishstat command, to see how many items have overflowed the varnish cache or if we have over provisioned our varnish cache. If n_lru_nuked is above zero or g_space is a low, you likely want to consider potentially increase your memory allocation for Varnish. ...

I was doing some health checks on some new brownfield projects we’ve taken on recently, ahead of migrating them to our own infrastructure. And I noticed that their NewRelic invoices seemed abnormally high for the amount of traffic the stores received. I was expecting most of the stores to still be in the free tier, or at least under 200/300GB total ingest. Looking at the “Manage Data” account page in NewRelic. Tracing data dominated the ingest graph, in all the cases it exceeded over 50% of total data and up to 80% in a few stores. ...

So it appears the Magento 2 Trojan order exploit (CVE-2022-24086) is making the rounds again. With the recent rise in exploit attempts I am going to go out on a whim, and assume the exploit kit was recently sold/released again. Trojan Order was identified and patched back at the start of 2022. The relevant security Bulletin is APSB22-12. It states versions 2.3.0 to 2.3.3 are not affected but any other versions below 2.4.3-p1 and 2.3.7-p2 are. https://helpx.adobe.com/security/products/magento/apsb22-12.html ...

Typically a lot of Magento 2 stores are slow to build, some taking up to and over an hour. This becomes a bigger pain point as stores grow and more themes & locales are added. Often optimising build time is often towards the bottom of the priority list. The Magento Static Content Deploy Docs provides a good amount of detail on this subject, and is a good read. Just remember, typically, your pipeline execution time also affects your time to release fixes to critical production issues. As well as your CI spend. ...

Often when debugging frontend functionality, I find myself reaching for access into Magento Javascript components. To either read the current state or invoke various methods within that component to test return values. But how do we do this? How do we get, lets say, the current quote? It’s quite simple really, we just call require instead of define like we would in a component. Slap a debugger call in the body and now you can play with that component to your hearts content. ...

There are a handful of guides on how to clean-up old Github Action Artifacts. The issue I have with the ones I’ve seen, is they are really convoluted solutions for such a simple task. I am making an assumption here that you are using the Github CLI tool. If you are not, then your missing out, go give it a go (even just for this task). You can even use the CLI directly within your workflows if you can to run the clean-up as a nightly task etc. ...

One of my clients have recently seen a surge in TOR traffic with zero conversion from them. And has requested for them to be blocked, since its no point in autoscaling the infrastructure, leading to increased cost, for non converting anonymous traffic. We have a few different ways to block TOR/Onion traffic, firstly we can just click some buttons in cloudflare and problem solved. But thats boring, and does not protect us if we move away from Cloudflare in the future (maybe they’ll deem we are a ’enterprise’ at some point 🙃). We have two other simple options, at the firewall (iptables in this case) or at the web server level. I am a fan of dropping traffic closest to the edge, so lets go over the firewall approach. ...

A simple two line Nginx config update can remove any reference of the polyfill Malware from coming out of your store. What is the Polyfill.io Malware? As you likely have already heard, the polyfill.io domain has been serving malware. And there is still a concerning number of sites that still are including scripts from that domain. Cloudflare and Fastly have both released alternative services that only require a change of domain. These are https://cdnjs.cloudflare.com/polyfill/ and https://polyfill-fastly.io/ ...

I’ve been sat on this post and POC for CosmicSting (CVE-2024-34102) for a little while, giving time for stores to patch the vulnerability. Chances are, if you still have not applied the patch your store will have been probed and compromised by now since there are a handful of POCs out in the wild. So I highly encourage you to make sure the patch is applied (its simple, a single file diff). And to download and run a malware scanner such as Ecomscan by SanSec (its free, although wont tell you the location of the infections). Since this allowed attackers to exfil any files on the server that the user running PHP had permissions for. It is highly advised you rotate your application key in app/etc/env.php as this will allow attackers to create new API tokens even after the patch is applied. ...

Flushing Magento 2 cache is simple right? Just click the Orange “Cache Clear” button in the Admin, or run php bin/magento cache:clean from the command line. Speaking to other developers and merchants, this seems to be the way everyone deals with refreshing cached content. Even if its just affecting a single page or product. It does not take a genius to realise flushing the entire Magento cache, means a significantly lower cache hit rate for the short term. They key impacts of this will be: ...