Optimizing runtimes are a very hot topic for Ruby development right now: Historically, both JRuby and Rubinius dynamically optimized Ruby code as they ran it, but soon they will soon be joined by the likes of TruffleRuby, ruby+omr, mjit, llrb and topaz.
Furthermore, it’s common for Ruby web services to lazily load classes and open connections to dependent systems. This allows for faster system start-up time, and reduces memory usage: unused code is not loaded, and unused connections are not started nor kept active.
Dynamic optimization and lazy start-up techniques when starting a web service have a big downside: When a Ruby web service boots up, it will take some time for the service to reach peak performance. In my own experience, MRI — the most commonly-used Ruby runtime — takes several seconds to hit peak performance, but more aggressively optimizing runtimes, such as JRuby, take several minutes to reach their highest-performing state.
This period of reduced performance, if ignored by service operators, is normally observed by service clients as a spike in request latency, with timeouts sometimes kicking in. (Not very unexpectedly, this issue is not specific to Ruby.)
During the warm up period, WarmBlanket connects as an http client to the web service and repeatedly performs a number of pre-configured common requests. By exercising most endpoints, all needed code is loaded, database connections are started, and dynamically optimizing runtimes can optimize the code paths being exercised.
As a result, when a service starts to receive production traffic, it is at or near its peak performance, and thus ready to provide an awesome service to its clients.