Skip to content

Precip 1.0.0
Compare
Choose a tag to compare
@jeffgeorge jeffgeorge released this 18 Oct 20:34
· 148 commits to master since this release
v1.0.0
9015db7

Precip 1.0.0 brings massive performance improvements, a few key bugfixes, and a few feature improvements we've had back-burnered for awhile.

Performance

We've done everything we can think of at this time to squeeze as much performance as possible out of Precip. Here are some perf comparisons between where we were a week ago, and where we are today:

  • HTTP Throughput: Up 238%
  • HTTP Processing Time: Down 71%
  • Puppet Provisioning Time: Down 35% (now typically under 5 minutes)

How'd we do all this?

  • We moved MySQL Storage from a directory being shared over NFS + BindFS to a Virtual Disk Image managed via the vagrant-persistent-storage Vagrant Plugin. This means MySQL is now effectively running like a native disk inside the VM and is just about as performant as we can possibly make it from a virtualized hardware perspective. Caveat: MySQL Storage is now capped to 32GB, though we could make this configurable.
  • We drastically reconfigured how we customize the resources available to the VM. A ton of stuff changed, but the heavy-hitters were giving the VM half of the host’s physical CPU cores (previously capped at 2), switching from "legacy" paravirtualization to explicitly KVM, and deferring DNS resolution to the host.
  • We restructured our Puppet Scripts to be Puppet-4-compatible, swapped out how PHP was being provisioned, and upgraded our base box to a new version that supports Puppet 4. Turns out Puppet 4 is faster, and we were wasting a bunch of cycles provisioning PHP poorly.

Bugfixes

In all this testing we found a couple small but important things that needed fixing. Some of these fixes conveniently and accidentally paved the way for features.

  • Return a Friendly Error Message if you provision with no config.rb, and don’t fail at all if the config.rb is empty
  • Completely refactor how we’re collecting hosts to be significantly less stupid and error-prone. (Note: Please never let me write "clever one-liners" in Ruby ever again.)
  • Mount the sites directory tree as vagrant:www-data, and mount it 775, which allows both the vagrant and apache users to do stuff to the docroots.

New Features

Finally, we also went back and implemented some pet features we've had kicking around as ideas.

  • PimpMyLog Support, accessible at precip.vm/pml. Pre-configures itself and everything during the provisioning process. Logs are still available at outside the box at /log, but now they're also being mounted and managed in such a way that PML can access them.
  • Custom SSL Cert handling. Turns out Chrome doesn't cache anything correctly if you've got a self-signed cert, even if you tell Chrome to accept that cert. You can now drop SSL Cert / Key / CA files into /ssl/ and reference them in config.rb.
  • Need Precip to be aware of some other manually-defined hosts in /etc/hosts? You can now configure those in config.rb so Precip can be aware of something like an external Solr server, or an API on another VM somewhere.

Experimental Stuff

Thanks to the fixes to how we're mounting the sites directory and upgrades available in Drush 7.x, we can now support Drush Aliases that interact with Vagrant like it's a true remote alias. These new @vmi aliases are being created alongside your @vm aliases and get installed via install_aliases.sh.

When you use any of these new @vmi aliases the following happens:

  • Host Drush looks at your vmi.aliases.drushrc.php
  • Host Drush opens an SSH connection to Vagrant, using Vagrant's auto-generated no-passphrase key
  • With an SSH connection opened, Host Drush tells Guest Drush running inside Vagrant to run whatever command you asked for against the Guest’s /srv/www/site path
  • Guest Drush seamlessly returns the results back to Host Drush, but Host Drush didn’t do anything to Drupal

In practice we’ve found @vmi aliases to be a bit slower compared to @vm, but they have the important bonus of not being based on a kludgy mess of hacks. The plan will be to eventually replace the @vm aliases with @vmi and drop all related messy hackery (like local-settings.inc) at that point, but for now they’re an experimental extra. Please try using them and report back.

Assets 2
Loading