As usual on Monday, we come with a new release. Unlike the past week, we are not introducing any new fancy UI feature, but several stability and performance improvements.

As noted in the past releases, we are experimenting with the WAL feature of SQLite, which allows better concurrency and thus ASYD performs better. It was time to take a deeper look into this, as it was causing some unexpected behaviors.

One of the things we noticed was the SQLite version distributed on Debian stable (wheezy) is really outdated: 3.7.13 being the last one from SQLite 3.8.8.3, and some features we were using are not available on that version.

We did changed all this so now ASYD is fully compatible with SQLite 3.7.13, but we highly encourage our users to upgrade to SQLite 3.8.8 as it offers way better performance than the old version.

Important: when upgrading to the new ASYD version please also update your gems (gem update) to get the latest Phusion Passenger version, currently 5.0.4, as some stability features depends on the new Passengerfile.json, which allows us to distribute some internal configuration for Passenger.

Full upgrade instructions (from inside the ASYD directory):

passenger stop
gem update
git pull
bundle install
passenger start

Active WAL Checkpointing

This is another of the new features introduced, to avoid constant sync operations which increases the disk I/O operations, the most active databases (notifications, tasks and hosts) are being actively checkpointed.

How does this work?

All the write operations on that databases are kept in memory. A background process checks periodically if the database has been written, and was idle for 10 seconds (meaning the write operations stopped or, at least, are occurring less often). In this case, we checkpoint the database, issuing a sync operation to the disk and writing all the changes.

This has a clear performance advantage, as all the write operations are done in volatile memory which is a lot faster, it also requires less disk I/O operations, and avoids any possible database corruption due to multithreading. On the other hand, it also has a downside: in case of power loss, the last operations won’t be written to the disk, but said this, if there is a power loss in the middle of a deployment, you won’t really need those notifications as you will likely have to re-deploy those systems again.

In short: ASYD is now a lot more stable and performs better, try it!

Full Changelog