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
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.
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
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
Published: June 12, 2020
WARNING Proceed with caution
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.
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
Published: June 9, 2020
$ 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>]
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.