Q1. I am very happy with Passenger/Thin/Mongrel for deploying my Ruby on Rails^TM web applications. Why should I try WebROaR?

If you want to make your deployments (more) simple, extract more performance from your application or want an integrated solution to view the run time numbers and get notified of exceptions, you should try out WebROaR.



Q2. Under which open source license WebROaR is available for me?

GNU General Public License v3 (or later)



Q3. What all Operating Systems does WebROaR run upon?

WebROaR has been tested on Ubuntu 8.1/9.04/9.10, Debian 5 (64 Bit), Mac OS X (v10.5 & v10.6) and Cent OS 5.2. Basically, it should be able to run on any *IX OS. Currently it does not support Microsoft(R) Windows.



Q4. I am sure you would have done some naive benchmarks and are showing off a bit. Where is your detailed procedure and results?

Well, this quote is obligatory whenever any benchmark comparisons are posted – "There are three types of lies - lies, damn lies, and statistics." We have tried to do a fair comparison (in our opinion) and have used real open source applications for benchmarking. Check out the details here and please do let us know if have missed something blindingly obvious.



Q5. Does WebROaR necessarily need a HTTP Server (like Apache or Nginx) in front of it?

No, it is a full fledged server in itself and supports HTTP.



Q6. (With a smirk) So you wrote your own HTTP handling module. Looks like you had a lot of spare time and patience. Is it?

No, we are not that dumb. WebROaR uses the brilliant libebb library that implements HTTP/1.1 grammar as per RFC 2616 including support for persistent, and chunked requests. Libebb’s HTTP Parser itself was inspired by Mongrel’s awesome Ragel based parser. (Beauty of open source software, one inspires the other and all of them keep getting better.)



Q7. I do not have the time to read through the documentation or the code. Quickly explain me the design so that I can give my expert opinion on it.

WebROaR has a head process that accepts connections, parses the HTTP request, and passes it to the appropriate worker process (that has the corresponding Ruby Web Application code loaded in it). Head and worker are both written in C, and use the terrific libev event loop for all the asynchronous and non-blocking socket communication with each other as well as the clients.

Worker loads up (aka embeds) the Ruby interpreter, the web framework and the application code in it. In case any exception occurs while processing a request or analytics have been enabled for that application, the worker process dispatches a message packet to Starling Message Queue.

WebROaR Analyzer daemon takes its own sweet time to dequeue messages, analyze them and stores the required data to a database.

A nice and simple Admin Panel Rails application running in one of the workers itself helps in easy UI driven deployment. It also shows all the run time numbers stored in the database in a variety of useful views, along with the list of exceptions that occur in the deployed applications.

All the server processes talk to each other (whenever required) using SCGI.



Q8. How good is this server? Can I run my production application on it? I might get fired (or my startup might tank) if it goes down (often).

Well, test your application in staging by simulating high user loads for a period of time. (Hours/Days/Months/Years is up to you). If you don’t see any issues, and think the server is cool enough to warrant a switch, please do it. Or if anything is getting in the way of the holy alliance of your application and our server, please let us know and we would try our best to make it happen.



Q9. What are your future plans with this software? Hope you are not a fly-by-night operator or an Investment Bank.

Our team is fully committed to this software for the longer term. You can expect regular bug fixes and improvements rolled out often. As far as new features go, we would implement what users request us the most.