Blog

Gatling disableFollowRedirect without KO

Published: September 11, 2020

I’m currently working on a Gatling simulation which involves sending traffic to an endpoint that issues an HTTP 307 response. For this load test I want to send requests to this endpoint, but I don’t want Gatling to follow the redirect. You can instruct Gatling to not follow the redirect by calling disableFollowRedirect:

http("My request")
    .get("/redirecting-url")
    .disableFollowRedirect

However, doing this will cause Gatling to flag the request as a KO, when the endpoint issues a 307 response.

Magento Image Cache Lock Contention Issue

Published: June 17, 2020

During a recent Magento v2.3.5 upgrade (which was ultimately rolled back), we saw severely degraded performance when rolling back the the previous version. In New Relic we could see the most time consuming transaction was /unknown.

Reviewing the transaction traces we could see that these were requests to generate resized images, and that almost all of the time was being spent on the Magento\Framework\Filesystem\Driver\File::fileLock function.

Clearing a Backlog of MySQL Queries

Published: June 12, 2020

Sometimes, for one reason or another, MySQL may get in a state where it has a massive backlog of queries to process. In these types of situations, your application will likely be experiencing major performance issues. Additionally MySQL (and your application) will likely struggle to regain stability without human intervention. While restarting the MySQL process could be an option, that comes with a lot of risk. Another option, is to selectively kill certain queries.

ERROR 1180 (HY000): Got error 5 "Input/output error" during COMMIT While Importing a mysqldump

Published: June 11, 2020

Recently, when attempting to import a database backup taken with mysqldump, I experienced the following error:

ERROR 1180 (HY000) at line 23703: Got error 5 "Input/output error" during COMMIT

A quick Google search lead me to Percona’s “How Big Can Your Galera Transaction Be”, which suggested that this error can occur when attempting to commit a large amount of data in a transaction. I checked the MariaDB error logs and sure enough found record that that’s what was happening here:

200611 11:24:34 [Warning] WSREP: transaction size limit (2147483647) exceeded: 2147483648

Using n98-magerun2 dev:console on Magento Cloud

Published: June 9, 2020

n98-magerun2’s dev:console feature can come in quite handy for debugging production issues. However, if you try to run it on Magento Cloud, you’ll get an error due the read only filesystem:

$ var/n98-magerun2.phar dev:console

In ErrorHandler.php line 61:

  User Notice: Writing to /app/<<REDACTED>>/.config/psysh is not allowed. in phar:///app/<<REDACTED>>/var/n98-magerun2.phar/vendor/psy/psysh/src/ConfigPaths.php on line 228


dev:console [-a|--area AREA] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [--root-dir [ROOT-DIR]] [--skip-config] [--skip-root-check] [--skip-core-commands [SKIP-CORE-COMMANDS]] [--] <command> [<cmd>]

Magento's Not Sane Google reCAPTCHA v3 Implementation

Published: May 19, 2020

Magento’s out of box Google reCAPTCHA implementation currently allows the merchant to select between three types:

• Invisible reCaptcha v3
• Invisible reCaptcha v2
• reCaptcha v2

The default is currently Invisible reCaptcha v3. Unfortunately, as we’ll see in this post, Magento’s reCAPTCHA v3 implementation is not sane and I would not recommend any merchants use it.

Let me elaborate.