WebROaR isn't ready for production, yet.

WebROaR http://webroar.in/, a Ruby web application server designed to support Rails and Rack based applications recently came to my attention. My currently preferred Rails stack is Apache2 http://httpd.apache.org/, Ruby Enterprise 1.87 http://www.rubyenterpriseedition.com/, and Passenger http://www.modrails.com/, using NewRelic RPM http://www.newrelic.com/features.html for notifications and metrics.  I wanted to see how WebROaR stacked up as a replacement.

I began my investigation the way I do any application. I start by writing an installation script.  My tool of choice for deployments right now is Capistrano http://www.capify.org, and I've recently been interested in Deprec http://deprec.failmode.com/, a framework of recipes built on top of Capistrano specifically designed to install on ubuntu, which by chance, is also my preferred linux distribution. So I decided to extend Deprec with a WebROaR installation recipe.

WebROaR began showing it's relative youth immediately.  I expect to be able to install a production application non-interactively. That is to say, I should be able to script the entire affair by passing values to the installer, configure, and make scripts via the command line.  The current version of WebROaR's install will prompt you for up to four different values and provides no mechanism to create a non-interactive install.

With Capistrano a non-interactive install can be worked around by examining output and responding as a user would with stored answers. Other deployment systems based on shell scripts will find installing WebROaR challenging.

The next issue to deal with is provisioning the application.  There was no mechanism, save rewriting the entire configuration file, to create a new application from Capistrano.  For this reason I left any configuration of the server or applications out of the deprec recipe.

The problem with re-creating the entire configuration via Capistrano is a simple one, when you install an application with Capistrano it doesn't normally have any concept of any other applications that may be hosted by your server.  So a rewrite of the entire config would end up wiping out all other applications unless pains were taken to make it tolerant.

Another sign that WebROaR is fairly young is that when I deployed a simple test application, the deploy scripts hadn't properly used the bundle command to unpack all of the application's dependent gems. It left the application in a really sorry state.  WebROaR's user interface didn't expose the error condition, nor was it able to serve the configured application.  It wasn't until I connected to the box via ssh and tried to run script/server in the applications deploy folder before I got any clue as to what the problem might be.  WebROaR should have done what it could to raise the problem to my attention within its exceptions section. I dealt with several errors where the WebROaR UI wasn't any help which gives me the impression there are many areas where WebROaR is rough around the reliability edges.

It's great that WebROaR's concept is built around interactive management, Apache, Passenger, Mongrel, and Thin don't really provide any instrumentation without something like NewRelic's RPM.

The exception reporting was definately useful, and presented nicely, if not exactly timely.  After triggering a few errors it still took several refreshes of WebROaR's UI before the information was ready to be examined.  Similarly there was a delay from when the first requests were generated before the graphs in the analytics could be reviewed.

Things like email and sms notifications are not in the product yet. I would have expected the ability to automatically send notifications and have some control over the process when metrics go above or beyond certain thresholds, or when certain types of exceptions occur.

The admin interface is protected by only a single username and password, multiple users aren't possible. Obviously role based access controls aren't in the product yet either.

The documentation is rather good for what features there are. But there aren't that many features.

I didn't do any kind of exhaustive performance benchmarks or stress tests because my curiosity had already been sated by getting my test application up. WebROaR doesn't compare to the configurability, stability, and breadth of options that I could even remotely consider it as a replacement for my current Rails Stack, even if all of it's claims about performance are true.

If it's going to become a production ready application, it's going to have to make it effecient for sysadmins to install and manage it from the command line and report error conditions better.  I can absolutely see it's alure to hosting companies as a great way to host rails apps if they can delegate control to end users and use an API to control the configuration. The project is very young, announced November 25th, 2009 according to their Blog, and it's incredibly promising, I'll definately check it out again when they get near a 1.0 release.


Deprec WebROaR recipe: http://github.com/donnoman/deprec/blob/2cdac7ed5c322d41512673a2e199707b3e47de...

Related changes to deprec: http://github.com/donnoman/deprec/commit/2cdac7ed5c322d41512673a2e199707b3e47...

Any fixes will be comitted here: http://github.com/donnoman/deprec/tree/webroar

Sample App Deploy Script using webroar: http://github.com/donnoman/flitten_deploy/commit/76e0ae350d75127fb43e7cc181f0...
1 response
Donovan,
Thank you for trying out WebROaR and sharing your thoughts here. It is great to get feedback and would certainly help in maturing up of this product. (I'm the co-creator of WebROaR.)

My comments on some of the things you have mentioned in this post:

1. *"I expect to be able to install a production application non-interactively"*

As of now, our main focus has been to make the server itself solid for the vast number of rails (& other rack) applications out there. We would definitely consider having the feature of a fully non-interactive install in the future versions.

2. *"WebROaR's user interface didn't expose the error condition, nor was it able to serve the configured application. "*

At this point, if WebROaR is unable to load an application it just informs the user on the Admin Panel and directs him/her to refer the log files. This certainly needs to be improved and we would try providing detailed error message on the Panel itself soon.

3. *"The exception reporting was definately useful, and presented nicely, if not exactly timely. After triggering a few errors it still took several refreshes of WebROaR's UI before the information was ready to be examined. Similarly there was a delay from when the first requests were generated before the graphs in the analytics could be reviewed."*

It taken approximately a minute before the Analytics & the Exceptions data shows up on the Admin Panel. (We have put this somewhere in the User Guide but i guess we need to highlight this on the Panel as well.) Worker processes post their analytics & exception data packets to a message queue. An Analyzer daemon dequeues these packets, processes them and writes out relevant information to the database. At this instant this daemon polls the message queue every minute and hence the small delay before the data starts getting accounted on the Panel.

4. *"Things like email and sms notifications are not in the product yet. "*

Email notifications are supported in WebROaR. They can be setup on the 'Configuration' tab of the Admin Panel. (Through either SMTP or Sendmail)

5. *"it's incredibly promising, I'll definately check it out again when they get near a 1.0 release."*

Thanks. We also hope you try it again soon, and you find it *more* useful the next time around. :-)

Aditya