It’s been a while since I posted anything about Docker. That’s mostly because I still don’t really use it for anything – playing around locally, testing and learning doesn’t count yet.
But just to keep the ball rolling, here are a couple of handy links for the ideas on how to improve your Docker images, so that Docker uses much less space, benefits more from caching, and brings up the containers faster:
Both articles are around the same theme – choose your base image carefully, try to minimize the layers, use only what you need, and don’t forget to clean up the disk space with “docker system prune“.
Jeff Geerling shares his tips for “Getting the best performance out of Amazon EFS”. Given how (still) new the Amazon EFS is and how limited is the documentation of the best practices, this stuff is golden.
tl;dr: EFS is NFS. Networked file systems have inherent tradeoffs over local filesystem access—EFS doesn’t change that. Don’t expect the moon, benchmark and monitor it, and you’ll do fine.
SQL Keys in Depth is an excellent read if you want to brush up on your knowledge of database keys and how they affect the performance of your application. For the laziest among you, here are the summary points, based on an extensive research of 60+ articles, StackOverflow questions and IRC discussions:
For each table:
- Identify and declare all natural keys.
- Create a
<table_name>_id surrogate key of type
uuid with default value
uuid_generate_v1(). You can even mark it as a primary key if you like. Including the table name in this id makes joins simpler. It’s
JOIN foo USING (bar_id) vs
JOIN foo ON (foo.bar_id = bar.id). Do not expose this key to clients or anywhere outside the database.
- For “join tables” declare all foreign key columns as a single composite primary key.
- Add an artificial key if desired for use in a URL or anywhere else you want to share a reference to a row. Use a Feistel cipher or pg_hashids to conceal auto-incrementing integers.
- Mark foreign keys to surrogate UUIDs as
ON UPDATE RESTRICT and to external artificial keys as
ON UPDATE CASCADE. Use your own judgement for natural keys.
Here’s an interesting article that was hanging around in my “to blog” tabs for a while now: How to Read Big Files with PHP (Without Killing Your Server). I found the title to be slightly misleading, expecting the good old advice of reading and processing files line by line rather than all at once. But it’s not that. It’s much better. It covers some techniques that aren’t that well known to the majority of the PHP developers – generators, streams, and filters.
Strongly recommended read!
Years ago I had the following script running as a cron job, but then I lost it somewhere. It took me a few minutes to find it again, but just in case I need it in the future, I’m saving it here.
mysqlcheck --all-databases -o
mysqlcheck --all-databases --auto-repair
mysqlcheck --all-databases --analyze
Found it here this time.
Here are a whole lot of “Performance Tuning – Tips & Tricks” directly from the Nginx team. I’m sure you’ve seen bits and pieces of these all over the place, but it’s nice to have them all together and from the credible source as well.
“PHP-FPM tuning: Using ‘pm static’ for Max Performance” looks at different process management settings in PHP-FPM: static, dynamic, and ondemand, and the way they affect performance. The default – ondemand – might work well for you if you have a large server with plenty of resources and not so many actual visitors. Running on a smaller instance, or expecting high spikes of traffic might require you to look into your PHP-FPM configuration and adjust it. The article is just what the doctor ordered.
Personally, I prefer having a dedicated instance for the web server, but that instance being as small as possible. With that, figuring out the correct settings for static process management is easier. It also minimizes all those nasty cases of running out of memory, swapping, and having an excessive CPU utilization. Which is especially useful when running on Amazon AWS instances.
Via this blog post I came across this PHP image optimization library, which somewhat reminds me of this blog post from a couple of years ago. As good as ImageMagick is, it takes time and effort to find all the right options. With Spatie Image Optimizer you have an almost out of the box solution for optimizing images in a variety of formats.
This package can optimize PNGs, JPGs, SVGs and GIFs by running them through a chain of various image optimization tools.
“htop explained” is a very detailed guide into the htop Linux system monitoring tool. Even if you are an experienced Linux user, and even if you are not a fan of htop (why aren’t you?), you will still find this guide useful, as it goes into a lot of detail on how htop figures out all the values and where Linux keeps bits and pieces of system information.
This Front-End Checklist is pretty awesome and quite extensive:
The Front-End Checklist is an exhaustive list of all elements you need to have / to test before launching your site / page HTML to production.
It is based on Front-End developers’ years of experience, with the addition from some other open-source checklists.
The best part is that large parts of this list are pretty easy to automate and integrate with your deployment / continuous delivery tool chain.