Development Seed Blog

One Solution and Why It Didn’t Work for Us

For the past month I’ve been working with Development Seed to get a fully functional Drupal website up and running on a usb drive for a project we’re working on with the American Institute of Architects’ Communities by Design initiative. And after a couple of setbacks, it works and it’s fast.

Jeff wrote about how we ended up getting the Drupal site – actually a community editable disaster relief kit – running on the stick. I wanted to follow that up with a run down of our first plan of action, which seemed like the perfect solution but in the end just didn’t work. Hopefully this explanation will save other developers some time. 

To get Drupal running on a stick we had two main challenges - getting everything we needed to run Drupal (a web server, PHP, and MySql) up on a usb stick and making it work on multiple operating systems.

After a bit of research, we came up with the following options:

WSOP

Pros:

• Already has everything on a stick, which would solve our problem of how to get everything on a stick

Cons:

• Only works on Windows
• Somewhat buggy and not well tested
• Still would need a solution that runs on operating systems other than Windows

XAMP

Pros:

• Many versions of the *AMP stack (WAMP, MAMP, XAMP)
• Includes everything

Cons:

• Fairly hefty size wise
• Has its own control panel
• Some of the other *AMP stacks are not well tested
• Servers run off the stick

Resin

Pros:

• Pure Java
• All PHP gets compiled into byte code and runs through the JVM
• On-demand compilation, so time is not wasted trying to compile the entire Drupal directory
• Can be setup to “pre-compile” the Drupal directory if we wanted

Cons:

• Requires Java
• Server files run on the stick
• Requires .NET (only for the interface, this is reliable as we could recompile the interface to use .NET 1.0)

Deciding on Resin

After all was said and done, we choose Resin because of its simplicity. By using this setup, we already had a web server, php, and modules up and running and it was a system that worked in different operating systems. It also contained some performance tweaks (APC cache is used by default), and Java has its own cache. Also, from the JVM stand point, it would all be compiled into java byte code and run through the JVM CLIENT side, leading to less traffic across the USB connection/bridge.

These were the other factors that convinced us to use Resin:

1. JVM - We thought that by using Java, we could have most of the http/web processing stack running client side.

2. Control – With Resin we could control the footprint of the JVM and other attributes. This also somewhat "sandboxed" the stack from other resources on the clients machine, and in essence gave us our own "predictable" environment to work in (this point is arguable).

3. Speed - In Resin all the PHP code is compiled. This in and by itself in such a small environment doesn't increase speed much. However, it does allow us to skip "interpretation" to some degree as it allows "pre-compiling" before running. Resin is also a pretty fast stack when running in interpreted mode.

4. Cross-Platform - By using Resin we didn't have to double our efforts to get the site running on other platforms, which allowed us to focus our resources on the application rather than the hardware/web stack. And we could run our "Drupal application" on Linux, Mac, Window, and cell phone’s operating systems with little to no change.

The Results

After getting everything set up on a stick, we got to see just how good our decision was. It turns out that the performance of Drupal on a stick with this set up was twofold:

1. On disk (local), it performed very well with very fast load times.

2. On the usb stick, the performance plummeted to as long as 15 seconds for a page load.

The slow page load times were obviously a big issue. But they were not due to Resin functioning poorly – they were due to MySql query calls and disk access problems. Anytime the “stick” is accessed or written to from the user’s machine, it’s a very slow process. Consider this: in testing the sticks, it took two minutes to read and copy 100MB to a local hard-drive/disk, but it took 40 minutes to write 100MB to the USB stick. Each write (which MySql does for table locks and row locks) took 20 times longer than reads. This was a problem.

The Resin server’s footprint also revealed some interesting activity. The average footprint was around 70MB, but it ranged from 50MB to up to sometimes 120MB in memory. All considered, this isn’t bad. Also Resin does come with configuration parameters to limit the amount of memory it uses.

For the most part, Resin was “very” stable, especially considering the volatile environment it was running on. I only had it crash unexpectedly on me once.

Conclusions

After my first run at getting Drupal working on a usb stick, I think the main concern isn’t what to use to get Drupal on a stick, but rather how can you handle the slow write times of a usb stick. This is the main question that must be answered after implementing anything on a stick.

When I read through the list of programs that are on our stick, this became more clear. Most of these programs run in memory and read or manipulate files on the local disk, and NOT on the stick. So if you can somehow manipulate your programs to visit the user’s computer/hard drive/system yet live on the stick (meaning move and run on the users computer), you may have solved your problem. And if you can figure this out, then using a usb stick to house your applications can have major advantages.

But we didn’t get this far. Instead, we used a different solution to get Drupal running on a stick. You can read about what did work for us here.