Sinatra-synchrony is awesome. For those looking to do a few more advanced use-cases, like HTTP streaming upload/downloads, websockets, etc.. Take a look at Goliath: https://github.com/postrank-labs/goliath
We tried Sinatra-synchrony, but had some problems with it with latest sinatra and ruby. Eventually I just used eventmachine-synchrony together with Rack::Fiberpool, which works just fine too.
I don't understand what you're referring to here. If anything I'd think Heroku customers are the most price-sensitive, and usually start with a free plan.
Are you kidding? Heroku is incredibly expensive once you move off the free plan (although I'm sure there's some people who will say that they're happy to pay extra so they don't have to learn how servers work)
That's a pretty condenscending attitude. For very rapid deployments, small shops, and many other use cases deploying on Heroku would be much cheaper than paying for personnel, hardware, leasing, and myriad other costs associated with running your own servers.
Heroku has very much to offer for shops that don't have much of an ops team. They solve a couple of problems quite nicely:
- Deployment (git push)
- Backups
- Database maintenance
- Database Backups
- Lots and lots of addons that are simple to install and provide consolidated billing.
- No server-maintenance at all.
Especially the last point is something that gets underestimated a lot IMHO. Having a linode VPS implies that you have to take care of that box, which is a major pain if you're not an ops guy. It's simple for people that do ops, but sooner or later I always find myself tangled up in some special sort of (Linux/BSD/...) problem that takes me hours to solve, hours I could spend much more efficiently in building a new feature. Having a single VPS won't cut it if you're trying to have a load-balanced setup that scales out when needed. You need at least two. And maybe a database. And then, the moment your app takes off, you'll need to provision servers faster than you can manually, so you need scripting. Go learn puppet. More time gone.
So while it is expensive, there's a lot of teams that benefit tremendously from using an expensive service that solves that whole sort of problems. And it's not that expensive either. If your app is somewhat conservative in what it does, you probably can get 5-10req/sec on a single worker.
The beautiful thing about Sinatra is that it is ridiculously easy to pick up and go. With even a small amount of Ruby knowledge you're up and running in no time.
One of the things I love about Sinatra is that pretty much everything you need to know is in the README. Otherwise, understanding how Rack/your web server/your gems work is useful. From another angle, Paul Dix's Service-Oriented Design with Ruby and Rails has a lot of examples of using Sinatra in a variety of applications.
I think you're reading it right on the plain Hello World benches, but the in the HAML and SASS benches node is already 2 to 4 times faster with no concurrency. I think this speaks a lot for the impressive speed of V8. HAML/SASS are originally Ruby libraries, and carry a few years of experience on their backs, unlike their javascript versions. These V8 numbers are even (far) more impressive: http://attractivechaos.github.com/plb
Disclaimer: I use Ruby and have no experience with Node.js.
Those benchmarks are not leveraging the concurrency that Sinatra::Synchrony brings to Sinatra. All this benchmark shows is that a concurrent application can serve out more requests than a non-concurrent application when tested concurrently.
