I've had a long history playing around with Raspberry Pis and other Single Board Computers (SBCs); from building a cluster of Raspberry Pis to run Drupal, to building a distributed home temperature monitoring system with Raspberry Pis, I've spent a good deal of time testing the limits of an SBC, and also finding ways to use their strengths to my advantage.
Back in 2015, I wrote a popular post comparing the performance of a number of microSD cards when used with the Raspberry Pi. In the intervening three years, the marketplace hasn't changed a ton, but there have been two new revisions to the Raspberry Pi (the model 3 B and just-released model 3 B+). In that article, I stated:
One of the highest-impact upgrades you can perform to increase Raspberry Pi performance is to buy the fastest possible microSD card—especially for applications where you need to do a lot of random reads and writes.
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.
On a recent project, I needed to have a shared network file system that was available to all servers, and able to scale horizontally to anywhere between 1 and 100 servers. It needed low-latency file access, and also needed to be able to handle small file writes and file locks synchronously with as little latency as possible.
Amazon EFS, which uses NFS v4.1, checks all of those checkboxes (at least, to a certain extent), and if you're already building infrastructure inside AWS, EFS is a very cost-effective way to manage a scalable NFS filesystem. I'm not going to go too much into the technical details of EFS or NFS v4.1, but I would like to highlight some of the painful lessons my team has learned implementing EFS for a fairly hefty CMS-based project.
Today while I was running a particularly large Ansible playbook about the 15th time in a row, I was wondering why this playbook seemed to run quite a bit slower than most other playbooks, even though I was managing a server that was in the same datacenter as most of my other infrastructure.
I have had
pipelining = True in my system
/etc/ansible/ansible.cfg for ages, and initially wondered why the individual tasks were so delayed—even when doing something like running three
lineinfile tasks on one config file. The only major difference in this slow playbook's configuration was that I had a local
ansible.cfg file in the playbook, to override my global
roles_path (I wanted the specific role versions for this playbook to be managed and stored local to the playbook).
So, my curiosity led me to a more thorough reading of Ansible's configuration documentation, specifically a section talking about Ansible configuration file precedence:
Pi Hole is a nifty open source project that allows you to offload the task of blocking advertisements and annoying (and often malicious) trackers to a Raspberry Pi. The installation is deceptively simple (a
curl | bash affair), but I wanted to document how I set up mine headless (just plugging the Pi into power and the network).
Set up Raspbian Lite
I bought a Raspberry Pi model 2 B along with the official Raspberry Pi foundation Case. Then I bought a Samsung Evo+ 32GB microSD card (which comes with a full-size SD card adapter), and did the following steps on my MacBook Pro to set up the Pi's OS:
XHProf, a PHP extension formerly created and maintained by Facebook, has for many years been the de-facto standard in profiling Drupal's PHP code and performance issues. Unfortunately, as Facebook has matured and shifted resources, the XHProf extension maintenance tailed off around the time of the PHP 7.0 era, and now that we're hitting PHP 7.1, even some sparsely-maintained forks are difficult (if not impossible) to get running with newer versions of PHP.
Tideways has basically taken on the XHProf extension, updated it for modern PHP versions, but also re-branded it to be named 'Tideways' instead of 'XHProf'. This has created a little confusion, since Tideways also offers a branded and proprietary service for aggregating and displaying profiling information through Tideways.io. But you can use Tideways completely independent from Tideways.io, as a drop-in replacement for XHProf. And you can even browse profiling results using the same old XHProf UI!
File this under the "it's a very bad idea, but sometimes absolutely necessary" category: I was working on a site that wanted to use a particular font for headlines throughout the site, but the client detested one particular character (an ampersand), and requested any time that character were to occur in the page title, it would be swapped out for a different font.
If at all possible, you should avoid doing what I'm about to describe—but in the off chance you need to have an automated way to scan a string of text and change the font family for one particular character, this is what to do:
First, you need to create a special CSS class that you can apply to the individual character, so in your theme's CSS, add something like:
On a recent project, there was a Migration run that took a very long time, and I couldn't pinpoint why; there were multiple migrations, and none of the others took very long at all (usually processing at least hundreds if not thousands of nodes per minute). In Drupal 7, if you enabled the XHProf module, then you'd get a checkbox on the configuration page that would turn on profiling for all page requests and Drush commands.
In Drupal 8, the XHProf module was completely rewritten, and as a side effect, the Drush/CLI profiling functionality is not yet present (see: Profile drush/CLI with XHProf in Drupal 8).
Since I don't have the time right now to help figure out how to get things working through the official XHProf module, I decided to use a 'poor man's profiling' method to profile a Migration run:
Recently, I was upgrading the infrastructure for Hosted Apache Solr, and as part of the upgrade, I jumped from Nginx 1.8.x to 1.10.x, which includes HTTP/2 support. I had previously used SPDY support in my server configuration to help the site run better/faster on modern browsers with SPDY support:
listen 443 ssl spdy;
After the server upgrades, I was getting the following error on Nginx restarts:
nginx: [warn] invalid parameter "spdy": ngx_http_spdy_module was superseded by ngx_http_v2_module in /etc/nginx/conf.d/hostedapachesolr.conf:10
So I switched the configuration to use
http2 instead of
spdy on the
listen line, and restarted nginx.
Everything worked great in Safari and FireFox, but when I tried loading the page in Chrome, I was greeted with the following error:
Drupal VM is one of the most flexible and powerful local development environments for Drupal, but one the main goals of the project is to build a fully-functional Drupal 8 site quickly and easily without doing much setup work. The ideal would be to install Vagrant, clone or download the project, then run
vagrant up. A few minutes later, you'd have a Drupal 8 site ready for hacking on!
In the past, you always had to do a couple extra steps in between, configuring a
drupal.make.yml file and a
config.yml file. Recently, thanks in huge part to Oskar Schöldström's herculean efforts, we achieved that ideal by switching from defaulting to a Drush make-based workflow to a Composer-based workflow (this will come in the 3.1.0 release, very soon!). But it wasn't without trial and tribulation!