WebROaR - Ruby Application Server

WebROaR v0.7.0 – Upgraded Admin Panel to Rails 3.0.9

2011-10-14T09:59:00Z

We are proud to announce release of WebROaR v0.7.0 with upgraded Admin Panel and few bug fixes.

There is no change to core functionality of the server. To make the server compatible with latest Rubygems, we have upgraded Admin Panel to Rails 3.0.9.

Here is the list of changes since v0.6.1 release:

Upgraded Admin Panel to Rails 3.0.9.
Fixed logic to find out latest installed version.
Fixed 'user.yml' file importing issue.

Install Commands

sudo gem install webroar
sudo webroar install

In case you have a previous installation of WebROaR, the install would give an option to import previous configuration, logs and admin panel data. Or you can also choose to install afresh and deploy your application(s) again.

Refer to WebROaR User Guide for more detailed information.

We are thankful to all the people who reported issues on Lighthouse and to the mailing list. We would be glad to receive more feedback/comments and bug-reports. Please run your ruby web applications on WebROaR and give us your valuable feedback. You feedback is much appriciated.

WebROaR v0.6.1 - Admin Panel Enhancement

2011-09-19T14:00:00Z

We are happy to announce the release of WebROaR v0.6.1 with a couple of new features and critical bug fixes.

Now the users can send their valuable feedback, and report any bug from "Contact Us" page of the Admin Panel. For that you need to configure mail setting from "Configuration" page.

This release added support to disable Admin Panel and Analytics feature. These features can be controlled from 'conf/serverinternalconfig.yml' file.

Previous version of Admin Panel shows backtrace and environment details of the last occurred exception. But now it shows backtrace and environment details from all the exceptions.

Here is the list of changes since v0.5.0 release.

New Features

Added Feedback and Report Bug forms in Admin Panel.
Support to disable Admin Panel on server startup.
Support to disable Analytics feature.
Show backtrace and environment details of each exceptions.

Fixes

Fixed server crashing issue with Ubuntu 11.04.
Fixed file import issue by importing 'serverinternalconfig.yml' file.
Now closing session after password change of Admin Panel.
Fixed SSL issue in libebb.
Changed images used in Admin Panel.
Moved Email module to Admin Panel
Added current directory in load_path($:) to make the server compatible with Ruby>=1.9.2.
Fixed Javascript and Stylesheet loading problem for Rails 3 Application.
Added helpers to run Admin Panel with Ruby 1.9.3.
Fixed invalid byte sequence issue to run Admin Panel with Ruby 1.9.2.
Corrected spec test cases.
Fixed condition satement to check Rails version in adapter.
Upgraded Admin Panel and Test App to Rails 2.3.9.
Upgraded openflashchart_2 plugin.
Corrected check condition to start exception tracker.
Defined modules for server commands.
Corrected default value of min and max workers for application
Added link to stop an application from Admin Panel.
Improved and cleaned up Analyzer module.
Fixed paginate plugin issue by correcting javascript to generate Ajax request.
Commented copyright message in Admin Panel's views.
Hacked 'environment.rb' to fix 'version_requirements' method issue with RubyGems 1.5.x
Fixed code compilation issue with Mac OS.

Install Commands

sudo gem install webroar
sudo webroar install

Refer to WebROaR User Guide for more detailed information.

WebROaR v0.5.0 - Supports gzip Encoding and Filtering Exceptions

2011-02-16T13:55:00Z

We are happy to announce the release of WebROaR v0.5.0 with some new features, enhancement and fixes.

This release added support to filter out known exceptions at application level and these filtered exceptions are listed in Permanently Ignored list.

The previous version of the server supports only 'deflate' encoding for static assets. Now, 'gzip' encoding is also supported with this release.

We have also added command line support to add/remove an application form its root directory. User can simply deploy an application from its root directory by executing command 'webroar add'. It would deploy the application using default parameters. Of course, you can pass parameters to overwrite default parameters.

Here is the list of changes after v0.4.0 release:

New Features

Added support to filter out know exceptions.
The number of exceptions displayed in exception list made configurable.
Support gzip encoding for static assets.
Support for adding/removing applications from its root directory with default parameters.

Fixes

Support to render static assets for Rails 3 application.
Updated test cases.
Implemented new YAML parser to handle lists and associative arrays.
Added client side validations on Admin Panel.
Code clean-up in Admin Panel.
Corrected rendering of graph partials.
Improve popup windows used to display help messages.
Corrected checkbox selection functionality on exception listing page.
Check Cache-Control header before choosing encoding. This fixes an issue of static content encoding on IE6.
Update values on Admin Panel home page using single Ajax request.
Wrapped multi statement macros in do..while structure.
Fixed rack dependency issue.
Improve the logic of exiting worker gracefully if there is an error.
Fixed starling dependency issue with Rails 3 application.
Kept strict dependency for Rspec 1.3.x.
Fixed QUERY_STRING issue faced with Rails 3 application.
Clean-up and improve migration scripts.
Updated libyaml to v0.1.3
Upgraded Libev to v3.9.
Improved Ajax call on Analytics page.

Install Commands

sudo gem install webroar
sudo webroar install

You can also refer the WebROaR User Guide for more detailed information.

We are thankful to all the people who reported the issues on Lighthouse and the mailing list. We would be very happy to receive more feedback/comments and bug-reports. Look forward to your support for WebROaR, please run your ruby web application on it and let us know how it goes.

WebROaR v0.4.0 - Supports Static Assets Encoding and Static Ruby Library

2010-08-09T12:56:00Z

WebROaR is under continuous development. We are happy to announce release of WebROaR v0.4.0 which contains new features, enhancements and bug fixes.

Previous versions of WebROaR were supporting 'gzip' and 'deflate' content encoding for dynamic response. In this release, we have added support for 'deflate' content encoding of static assets. By default content encoding is supported for content type 'javascript|css|xml|text' having actual content size greater than 1KB and less than 10MB for all the user agent. Content type, size and user agent is configurable through 'config.yml' file.

Here is the list of changes after v0.3.1 release:

New Features

Supports deflate encoding for static assets.
Support for passing environment variables to application.
Support to build server with static Ruby library.

Fixes

Tested on Ruby 1.9.2 RC2
Tested on Ubuntu 10.04.
Directory path expanded when application is added from command line. (It would allow to pass relative path)
Fixed incorrect response code of static assets by using 'timegm' function instead of 'mktime'.
Requiring version.rb using relative path, to work with Ruby 1.9.2.
Added Config::CONFIG['rubyhdrdir'] in ruby headers search path for Ruby 1.9.
Sends '503 Service Unavailable' response, if pending message queue overflows.
Code cleanup in Rake tasks.
Enhanced SCGI request parsing in Admin Panel to handle chunked request.
Added tests for application add, remove and zero down time during restart.
Added Config::CONFIG['includedir'] in include directory list.
Supports Rails 3 application.
Created 'config.yml' file with default configuration if it is not found while importing.
Added support to start/stop/restart static-worker.
Support to view analytics data for all the application, earlier it was only for the application which has analytics enabled.
Saving log files after executing load test.
Improved rake task to execute test-suite.
Set Expires headers from Admin Panel.
Server specification code cleanup in Admin Panel.
Passing application configuration parameters to worker using SCGI.
Email notification for the captured exceptions made configurable.
Made many server parameters configurable through config file 'serverinternalconfig.yml'.
Sends ERROR control message, if application could not be loaded by worker.
Wait for 30 minutes before creating new worker, if three consecutive newly created worker got timed out.
Removed 'Cache-Control' response header from static assets. Its incorrect handling choking IE 6.

Install Commands:

sudo gem install webroar
sudo webroar install

You can also refer the WebROaR User Guide for more detailed information.

Team Changes

2010-03-25T12:09:00Z

Sadly Aditya has decided to pursue his other aspirations, given his new dream would require a substantial amount of his time, he would no longer be actively contributing to the project. Best of luck to him.

While Aditya will be missed, we have exciting new features to be built in WebROaR for which Dharmarth, Nikunj and I would continue to support the project as usual. You can communicate with me on vineet DOT tyagi AT webroar DOT in

PS: We would be looking for more like minded people to join the project, if you think you have what it takes please drop us an introduction at vineet DOT tyagi AT webroar DOT in

WebROaR v0.3.1 - Supports Zero Downtime Application Upgrades

2010-03-22T16:41:00Z

We are happy to announce the release of WebROaR v0.3.1 that supports Zero Downtime Application Upgrades.

The previous versions of the server already allowed restart of a single application at a time without affecting the other apps hosted on it. We have further improved the logic now, to ensure even the particular application being restarted, does not become unavailable at any time.

Here is the sequence of events when an application is restarted:

The head process receives a request to restart one particular application. This can happen through sudo webroar restart [APPNAME] command triggered via console or a Capistrano script. The application can also be restarted through the Admin Panel.
Head forks off a new worker asking it to load the upgraded application from the disk.
As soon as the new worker successfully connects back, the head kills off the free old workers.
If current worker count is less than the minimum number of workers configured for an application, head instantiates the desired number of new workers to reach this threshold limit.
All new/pending requests are sent to the new worker(s).
The busy old workers gracefully exit after processing their current request. A new worker is instantiated for each busy worker that exits. (This controlled spawning of new workers ensures judicious use of system resources especially the RAM.)

Essentially, the aim is to ensure that the server processes all the requests properly without any error(s) or any kind of slow down.

Of course, this strategy would not work well for upgrades involving migrations. But it does come in handy for on-the-fly code updates without throwing yet another 'Under Maintenance' notice for the customers.

Here is the list of changes after v0.2.6 release:

New Features

Support for Zero Downtime Application Upgrades.
Full support for adding/removing applications from command line. (Earlier it was only possible through the Admin Panel.)
Full support for non interactive installation of the server.
Support for passing additional include and library paths for server compilation.
Display error trace directly on the Admin Panel or the console if the application start/stop/restart command fails.

Fixes

Moved Admin Panel to our vendor Rails to fix ActionPack 2.3.5 and Rack dependency issue.
Fixed unit tests to make them run on Mac OS and Arch Linux.
Query optimizations on exception listing page of the Admin Panel.
Usability improvements on exception listing page of the Admin Panel -
Pagination and multiple selects.
Stopped sending email notifications for ignored exceptions.
Fixed overruling of the '--ssl-support' option while importing configuration file from a previous installation.
Fixed service script generation issue for Arch Linux (Ticket #4).
Handled Memcache client's timeout error by overriding timeout value to 15 seconds when sending worker's PID (Ticket #14).
Handled application control signal connection breaking issue.
Fixed multiple host name resolving issue (Ticket #15).
Fixed the handling of static files with extensions in Upper Case.
Fixed flash crash issue when viewing URL graphs for the applications having data for 40K or more requests.
Fixed overruling of access log setting while updating the SSL configuration.
Removed dependency of starling-starling gem on Github. The server now uses starling gem on Gemcutter.
Removed application from server's in-memory list if all of it's workers
fail to connect back to the head.
Solved the Admin Panel menu options vanishing issue by setting color of the links on the top menu bar.
Set default value of minimum and maximum numbers of workers to 4 and 8 respectively in wr_config.h
Code cleanup in Analyzer and 'lib' modules.

Install Commands:

sudo gem install webroar
sudo webroar install

You can also refer the WebROaR User Guide for more detailed information.

We are thankful to all the people who reported the issues on Lighthouse and the mailing list. We would be very happy to receive more feedback/comments and bug-reports. If you have some time, please run your ruby web application on it and let us know how it goes.

WebROaR v0.2.6 - Bugfix Release

2009-12-23T09:58:00Z

WebROaR v0.2.6 gem is now available with the following fixes:

Updated messages for HTTP status codes 400, 404, 405, 500 and 501.
Fixed buffer overflow by allocating enough memory to hold REQUEST_PATH + Application-Path in the request resolver for static assets.
Improved the logic for detection of ruby shared library prerequisite.
Started using RUBY_INSTALL_NAME for detecting ruby during installation.
Added validation for search results file created while generating service script. Installation would continue even if server cannot be installed as a service.
Corrected example for the 'Headers' section in the config file.
Removed 'SIGCHLD' handler from the worker process - Fixes the incorrect exit status issue for a shell command executed using backquote method of ruby.
Added HTTP Date header when the HTTP response status is 100.
Used _POSIX_C_SOURCE macro to identify whether the file variable is a pointer to a file or a socket fd.
Corrected return type of 'send_static_worker_pid' method, if YAML parser returns NULL value.
Corrected time slider based analytics graphs issue when they were being seen after 2300 hrs.
Correctly implemented Rack specification for the Response Body. This fixes worker crash seen after serving first request in Development Environment mode for Rails 2.3.4+ applications.
Overriding Rack::Deflater to skip response body compression for user-agent Internet Explorer 6.0.
Renamed 'log' message defined by rb_define_singleton_method() to 'log_message'. This fixes the issue seen when Math.log is called by number_to_human_size() in a Rails Application. It also fixes the worker crash on REE installed with tcmalloc library. (Typically used to result in 404 error for a user trying to access the Admin Panel.) Resolves Tickets #9 and #10.
Code cleanup in Head, Worker and Helper modules.

Install Commands:

gem sources -a http://gems.github.com
sudo gem install webroar
sudo webroar install

WebROaR v0.2.5 - Tested on Snow Leopard & Ruby Enterprise Edition

2009-12-07T13:08:00Z

WebROaR v0.2.5 gem is now available on Gemcutter. Change log for this release:

Tested on Mac OS X v10.6 Snow Leopard & Ubuntu 9.10 (64-bit).
Tested on Ruby Enterprise Edition 1.8.7-2009.10.
Upgraded rack dependency version to >=1.0.1.
Upgraded rails dependency version to >=2.3.5. Resolves Ticket #6.
Redirected 'rake spec' output to STDOUT by default to indicate progress of test execution.
Implemented exception handling (that works both on ruby 1.8 & 1.9) for handling errors raised in scripts being run by the embedded interpreter in the worker.
Redirected standard IO right after logger is initialized in worker.
Handled absolute path for install dependencies. Resolves Ticket #3 - 'Unable to locate gcc on Snow Leopard during installation'.

Install Commands:

gem sources -a http://gems.github.com
sudo gem install webroar
sudo webroar install

We are trying to make the server more robust and stable, and would be very happy to receive feedback/comments and bug-reports. If you have some time, please run your ruby web application on it and let us know how it goes.

WebROaR v0.2.4 - Bugfix Release

2009-12-02T12:01:00Z

We pushed WebROaR v0.2.4 gem to Gemcutter last night with the following fixes:

Fixed intermittent crash issue in head while closing client connections by calling close_connection() directly rather than running it through goodbye_watcher in libebb.
Renamed on_error callback (introduced by us in libebb) to the more appropriate on_request_parse_error.
Fixed install issue on ruby 1.9 caused due to invalid multibyte char.
Fixed the incorrect month value in the file name format for gcore dumps.
Initialized logging for the worker right as it is instantiated before it connects to the head process.
Cleaned up wr_wkr_create() method in head/wr_worker.c.
Print logging level as a string in the log files.
Fixed invalid pointer being used in 'wr_req_resolve_http_req' function.
Fixed creation of rack.input stream object. Resolves Ticket #2 related to error seen on posting form with enctype="multipart/form-data".
Ensured 'starling-starling' gem is used by WebROaR even if 'starling' is present on the system.

Install Commands:

gem sources -a http://gems.github.com
sudo gem install webroar
sudo webroar install

We are trying to make the server more robust and stable, and would be very happy to receive feedback/comments and bug-reports. Please run your application on it if you have some time and do let us know how it goes.

Comparison of Rails Deployment Stacks

2009-11-25T22:04:00Z

Why?
Why write this post in the first place?
To showoff your cool stuff?
To deride the other perfectly good software?

No, the only reason I am writing this post is to back up our statement that WebROaR is generally much faster than all other comparable deployment stacks. The aim is to provide real world data and insights in to our benchmarking procedure for everyone. Honestly, there is not much fun in performing this long experiment, as we programmers do have very short attention spans. (Oh wait, let me see HN/programming reddit once again ...).

The results of this comparison should be just taken as an indicator and should act only as one of the many data points in coming up with your own conclusion about Rails deployment stacks. If you are seriously interested to know the performance numbers of your application, please do try this experiment at home. :-)

Benchmarking Basics

I can't put across the basics more 'eloquently' than this Zed Shaw essay and would recommend giving it a read. There are no 'eye-opening', 'lift the darkness' kind of insights in that essay, but at times we do make obvious blind mistakes while benchmarking that can be easily avoided. I hope we haven't made many of those in our experiment.

We tried taking care of the following aspects for this experiment:

Ensure the rest of the environment is exactly the same (as much as possible) for all deployment stacks being tested i.e. same hardware, same software versions, same test application and same tester as well. :-)
Use the right benchmarking tool that provides relevant and useful statistics.
Do not make it a "Hello world" application comparison that is potentially not useful in any which way in real world.
Allow each server stack to initialize/warm-up as required before running a performance test over it.

We selected httperf for conducting this experiment for it's ability to provide the relevant statistics. The data presented below should vouch for its usefulness.

I would also recommend this PeepCode screencast that provides a very good introduction to benchmarking with httperf. (Disclaimer - It's not free and we don't get any affiliate money referring it :-) )

Test Environment

Server Machine
CPU - Intel Core 2 Duo 2.8 GHz
RAM - 1GB
OS - Ubuntu 8.1(Intrepid) Desktop
Kernel - Linux 2.6.27-7-generic
Ruby - 1.8.7(2008-08-11 patchlevel 72) (Ubuntu Package)

Client Machine
CPU - Intel P-IV 2.66GHz
Memory - 1 GB
OS - Debian 5.0 (lenny)
Kernel - Linux 2.6.26-1-686

Benchmarking Tool
httperf -0.9.0 compiled without DEBUG and without TIME_SYSCALLS

Network Connectivity
100 MBPS LAN (1 hop between two machines)

Application
Name: Instiki
Source: http://github.com/parasew/instiki
Commit: 77dcb015f38d75d32df6fceb52ce4a2737845991
Rails Version: 2.3.4
Database: SQLite 3
URL: /wiki/list

We have tried to use a URL that has database interaction so as to simulate a typical scenario of a web application. This would ensure most parts of the Rails stack are involved in the test. Please note that caching is not enabled at all for this URL.

Deployment Stacks
We chose the following servers for this comparison.

Apache 2.2.9 (mpm-prefork) (Ubuntu Default) + mod-proxy-balancer + Mongrel 1.1.5 Cluster (6)
Apache 2.2.9 (mpm-prefork) (Ubuntu Default) + Passenger 2.2.7 (MaxPoolSize = 6)
Apache 2.2.9 (mpm-prefork) (Ubuntu Default) + mod-proxy-balancer + Thin 1.2.5 Cluster (6)
WebROaR v0.2.3 (Set 6 maximum workers for the deployed application)

Since the focus of our test is to compare maximum requests/sec output by each of the stacks, and the specific request is being served out by Rails from the database, replacing Apache with Nginx should not give us too dramatically different results. (As I mentioned earlier, these tests are just indicative of what performance level you can generally expect from your server.)

We would be happy if someone can repeat the test with Nginx as well.

Procedure

Strategy

We would like to find out the maximum requests/sec output by each server when the selected application URL is bombarded with requests from httperf.

Consider this command:

httperf --hog --server ABC --num-conns 2000 --num-calls 10 --uri /wiki/list --rate 11

It tries to make 2000 connections to the server ABC and sends 10 requests through each, for the URL /wiki/list. The total number of requests made are 2000*10 = 20,000. The 'Demanded Request Rate' is the product of rate and num-calls parameters i.e. 11 * 10 = 110 requests/sec.

The output would look similar to the following if the server is able to handle this load:

httperf --hog --client=0/1 --server=ABC --port=80 --uri=/wiki/list --rate=11 
--send-buffer=4096 --recv-buffer=16384 --num-conns=2000 --num-calls=10

Maximum connect burst length: 1

Total: connections 2000 requests 20000 replies 20000 test-duration 181.970 s

Connection rate: 11.0 conn/s (91.0 ms/conn, <=13 concurrent connections)
Connection time [ms]: min 107.4 avg 321.2 max 1724.8 median 238.5 stddev 228.1
Connection time [ms]: connect 0.2
Connection length [replies/conn]: 10.000

Request rate: 109.9 req/s (9.1 ms/req)
Request size [B]: 75.0

Reply rate [replies/s]: min 97.2 avg 109.9 max 117.4 stddev 4.0 (36 samples)
Reply time [ms]: response 31.8 transfer 0.3
Reply size [B]: header 465.0 content 4930.0 footer 0.0 (total 5395.0)
Reply status: 1xx=0 2xx=20000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 29.39 system 151.45 (user 16.2% system 83.2% total 99.4%)
Net I/O: 587.1 KB/s (4.8*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

The important fields to look from the above result are:

Reply rate [replies/s]: min 97.2 avg 109.9 max 117.4 stddev 4.0 (36 samples)

This tells us that average reply rate was 109.9 RPS with a standard deviation of 4. This was measured over 36 samples by httperf that samples every 5 seconds. (This specific test ran for 181.970 seconds). For the statistically inclined, Avg RPS +- 2*Std Deviation should give you 95% of the values.

There were no errors reported.

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

From this test we can conclude that the particular server under test can easily handle the demand rate of 110 RPS without any errors, and can be subject to more load.

Our aim is to find the maximum avg reply rate output by each server when subject to a series of high demanded request rates. After a specific demanded request rate test has been done, the server is restarted and warmed up before running next higher demanded rate test.

As we keep on increasing the demanded rate, the server would get saturated and its reply rate would not increase, and rather slowly start to degrade after a point. It could also start throwing errors.

We would like to find the saturation point for each server and the maximum avg reply rate output at that point.

Key Points

All possible additional applications/daemons should be stopped.
Rails environment should be set to production.
At any given point of time only one server deployment should be active on the machine, and it should run only the rails application under test.
Set Analytics to 'Disabled' for the deployed rails application on WebROaR. To ensure a fair comparison, we recommend turning off this feature to get the fastest performance for your application on WebROaR.
Ensure each server is initialized and warmed-up properly for every test i.e. it has loaded all it's resources and in case of Passenger & WebROaR they have already instantiated it's maximum number of workers. We used the following command for warming up all server stacks before running each of their tests.
```
httperf --hog --server ABC --num-conns 200 --num-calls 10 --uri /wiki/list 
--rate 20
```
After each test, the server should be shut down, and tmp folder, log files and sessions should be cleared.The commands that can be used are rake tmp:clear, rake db:sessions:clear and rake log:clear.
To get the memory usage numbers for each server, we used this simple technique that I first saw on the benchmarking blog of the good folks at Phusion Passenger. Essentially, just after the load test use the free -m command to see the free memory in the system, and then check it again after shutting down the server. The difference of these 2 numbers gives us the actual amount of memory the server stack was consuming. E.g. If free -m reported 300 MB free after the test, and 550 MB when the server was shutdown, the total memory usage of the server was 550-300 = 250 MB.

Results

For this particular test, WebROaR is able to handle the maximum demanded request rate among all the deployment stacks. Even after it gets saturated its performance doesn't degrade and there are no errors.
Passenger & Thin started giving errors, hence the graph software automatically got their reply rates to zero which is not statistically true, but emphasizes the point in a way.
Mongrel also behaves nicely after saturation and doesn't throw any errors.
Please note that Thin is able to handle the load very well before it breaks out at around 178. Its green line is merged with WebROaR's till that point and not visible in the image above.

The maximum RPS numbers for each of the deployment stack are:

Apache 2.2.9 + Passenger 2.2.7 (6) - 107.3
Apache 2.2.9 + Mongrel 1.1.5 Cluster (6) - 123.8
Apache 2.2.9 + Thin 1.2.5 Cluster (6) - 178.4
WebROaR 0.2.3 (6 maximum workers) -188.8

As per this test, on an average WebROaR is

~76% faster than Passenger
~52% faster than Mongrel
~6% faster than Thin

Remember, this is just one particular action of one particular application. It is not wise to derive a conclusion for each and every application based on the above result.

Let's look in to more details given to us by httperf.

The above table has the detailed numbers for test run of each deployment stack where it performed at its best. (Avg RPS +- 2*SD) range gives us a good idea of the performance of the server for 95% of its samples. WebROaR has the smallest standard deviation of 1.5 giving us a good indicator of consistency in its performance across all requests.

Also looking at the above table, we can safely say that for this test Network I/O was not a bottle neck at all.

Memory usage numbers for each of the deployment stack when they are delivering their maximum RPS are:

Apache 2.2.9 + Passenger 2.2.7 (6) - 133 MB
Apache 2.2.9 + Mongrel 1.1.5 Cluster (6) - 368 MB
Apache 2.2.9 + Thin 1.2.5 Cluster (6) - 231 MB
WebROaR 0.2.3 (6 maximum workers) -258 MB

For this test, Passenger consumed the least amount of memory followed by Thin.

More Performance Testing

We picked up 2 more open source Rails applications and tested them out using the above procedure.

Application
Name: Redmine
Source: http://github.com/edavis10/redmine
Commit: c9bfdc009baf9aa472b82543fbb3189ff9862b48
Rails Version: 2.3.4
Database: MySQL 5.0.67-0ubuntu6
URL: /projects

Application
Name: El Dorado
Source: http://github.com/trevorturk/eldorado
Commit: eac99d4b3cdd95782c3bc8e0642c7e3b0380017a
Rails Version: 2.3.3
Database: MySQL 5.0.67-0ubuntu6
URL: /users

Here are the results:

As per the tests, on an average WebROaR is

15 to 36% faster for the tested Redmine URL
9 to 39% faster for the tested El Dorado URL

than other servers.

The above memory usage graph indicates Passenger & WebROaR seem to be less memory hungry than the other 2 servers. (At least for these applications!)

More Performance Testing (with a different tool)

We also tested out the 3 applications (Instiki, Redmine and El Dorado) with 'ab'. In our opinion, 'httperf' is more reliable and provides more useful information, but we thought it would be a good idea to cross-check if 'ab' is giving similar (if not exact) results.

The following command was used to 'warmup' the server stacks:

ab -c20 -n2000 [Application URL]

The actual test:

ab -c20 -n20000 [Application URL]

The tests with 'ab' also confirmed the trends seen with 'httperf' and WebROaR does seem to be doing better than the other servers.

The memory usage numbers again corroborated the earlier finding of Passenger and WebROaR being less memory hungry than other 2 servers.

The complete set of raw results data can be downloaded from here.

Conclusion

How much should one really read in to the numbers above? Does WebROaR beat all other deployment stacks every time by these margins?

Well, we would suggest taking these numbers as indicative of how your application might perform on WebROaR. You may or may not see these exact gains (could be higher or lower), but you can safely assume that mostly there would be some decent gain performance of your application if it runs on WebROaR.

Apart from performance, we believe WebROaR brings a whole lot of simplicity and an integrated solution for Ruby on Rails™ application deployment. Do check it out and run your application on it when you have some time!

We would be happy to receive your feedback/comments/suggestions on this article.

Introducing WebROaR v0.2.3: Ruby Application Server

2009-11-25T22:03:00Z

We are happy to announce the first public open source release of 'WebROaR - Ruby Application Server'. This product is available for free use under GPL v3.

WebROaR aims to make the deployment of Ruby on Rails™ applications more simple, and provide an integrated solution to monitor the performance of the application and track its exceptions. This is facilitated by a simple and easy to use admin panel of the server.

It also is the best performing server as per "our" benchmarks. We absolutely encourage you to perform your own tests and then arrive at a conclusion. :-)

Features

Simplified Deployment for Ruby on Rails™ as well as other Rack compliant applications
Beats all other deployment stacks in benchmarks
Runs multiple applications simultaneously
Implements HTTP/1.1 grammar as per RFC 2616 including support for persistent, and chunked requests
Provides run time performance data for the deployed applications
Generates notifications in case any exceptions occur in any of the deployed applications
Intelligent load balancing and dynamic reaping of stuck Ruby processing instances
SSL support

Server Internals

I am sure some of you would be keen to know about the design of the server. Here is a primer:

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. The server smartly manages its pool of worker processes for each deployed application based on the request load. (For each deployed application, both minimum and maximum number of worker processes limits can be configured.)

Obviously, rather than writing HTTP handler on our own, we decided to use 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.)

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 if 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.

Overall, we have used C for asynchronous network communication stuff, and Ruby to write the more fancy things quickly.

Roadmap

Of course the first and foremost thing is to see how the server fares for all the Rails applications out there in the wild. We have tested it with our internal/customer applications and a number of open source ones. But obviously as more apps are (hopefully) run on it, and encountered issues are fixed, we hope the server would become more stable and robust.

As far as new features go, we have a few things on top of our mind but would be keen to hear from the community on how we can improve this product and make it more useful.

Finally ...

If you have some time, please do give it a spin and see how your Rails application performs on WebROaR. You can refer the install instructions on the site home page.

We would look forward to your comments/feedback.