There is always more implicit knowledge than documentation. (Which resulted in me changing my laptop issuance policy of to ‘Issue once configured’ vs the current ‘Here is your laptop and instructions’. The next evolution will be central management of policy, etc.
The default polling interval for Laravel workers is 3 seconds. If you have certain queues that are more time sensitive, you need to adjust accordingly. But you can only go as low as 1 second. This is another known issue with Laravel that is important when you build larger apps beyond toys. File under ‘things I shouldn’t have to do’
Sometimes, its not [just] a query that is misbehaving that is causing a problem, but is a query running in a loop. And you are one of only 5 or 6 people who can trigger it due to environmental stuff.
Environment matters. Our current nasty performance problem will only be triggered in production.
I have completely lost all comfort doing frontside turns on a snowboard
created_at, which is a fields that is created when using timestamps in Laravel Models/Migrations, is not indexed by default. So any time you use the built-in latest() or oldest() functions on an Eloquent query, you are doing a full table scan. There was an issue raised, but of course got shut down by the maintainer. Seriously, it annoys the hell out of my how small scale the Laravel team thinks. Scaling wut? At least when DHH was creating Rails he had a huge application to build/maintain. What’s Laravel got? Oh, a bunch of ecosystem stuff…
Observability throughout a distributed system is a pain. I’ve been trying to diagnose a performance bottleneck and tracking a request through 3 difference systems is a challenge. I need to somehow inject an id into incoming messages and flow it through. And messages that are originated in the system on their way out.
I found the source of the bottleneck at least. It looked like it was in an Eloquent save() call. Buuuut, its in an Event Observer on the ‘created’ event. I so wanted to blame the framework…
