Re: Ruby best practice for "always on" app/service?

On Wed, Jul 14, 2010 at 9:52 PM, Richard Conroy
<[e-mail]> wrote:
> Well everything is Rack enabled now. Install Passenger, deploy your
> Rack enabled web service proxy (simple sinatra apps are always good
> for these kind of things), and put your feet up.

It can be even easier... using JRuby, gem install trinidad and run it like =
this:

trinidad --threadsafe --rackup config.ru

One process, one instance, solid runtime, and as many concurrent
requests as you can throw at it:

~/projects/jruby =E2=9E=94 cat hello_world.ru
hello_world =3D lambda do |env|
  [200, {"Content-Type" =3D> "text/plain"}, ["Hello World!"]]
end

run hello_world

~/projects/jruby =E2=9E=94 trinidad --threadsafe --rackup hello_world.ru

...

~ =E2=9E=94 ab -c 100 -n 1000 http://localhost:3000/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Apache-Coyote/1.1
Server Hostname:        localhost
Server Port:            3000

Document Path:          /
Document Length:        12 bytes

Concurrency Level:      100
Time taken for tests:   0.440 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      166720 bytes
HTML transferred:       12504 bytes
Requests per second:    2274.66 [#/sec] (mean)
Time per request:       43.963 [ms] (mean)
Time per request:       0.440 [ms] (mean, across all concurrent requests)
Transfer rate:          370.34 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   13  10.2     13      34
Processing:    12   30  10.7     29      72
Waiting:        9   24   8.2     24      67
Total:         17   43  10.2     43      73

Percentage of the requests served within a certain time (ms)
  50%     43
  66%     45
  75%     48
  80%     49
  90%     54
  95%     63
  98%     65
  99%     67
 100%     73 (longest request)

> Rack compatible web container + Rack app is pretty much standard
> practice for deploying Ruby web based solutions nowadays. Deploying
> non-Rack ruby web apps would be considered an architecture smell now.
> Only exceptions in my mind would be JRuby specific deployment options
> like Warbler. Glassfish and the JBoss option (sorry cant think of it now)=
,
> and
> some of those are Rack-enabled too.

The JBoss offering is called TorqueBox. It's a server and a lot more;
there's wrappers for web services, timed/offline jobs. Maybe a little
heavy for a one-off service, though.

> Note that if this delay is significant (500ms+), you are likely to need a
> background job
> scheduler too, of which there are many in Ruby (Delayed Job seems to be
> getting
> very popular now).

If the delay is significant, you should use JRuby with a threadsafe
framework. About three hours ago I demonstrated JRuby + Trinidad +
Rails easily handling 100-way concurrency against a 0.5s-delayed
action. So easy it should be a crime.

- Charlie