Sinatra::Synchrony - Evented, fast, concurrent Ruby web apps with no callbacks | Hacker News Reader

Sinatra::Synchrony - Evented, fast, concurrent Ruby web apps with no callbacks

kyledrake.net

161 pointskyledrake30 comments

Neat; I hadn't heard of EM-Synchrony before. Here's a blog post explaining it: http://www.igvita.com/2010/03/22/untangling-evented-code-wit...

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

Same idea, em-synchrony under the hood.

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.

this will save heroku users serious money.

If you're running on Heroku you probably don't care about saving money...

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.

There is a good middle ground between Heroku and setting up your own hardware: VPS hosting like Linode.

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.

Hell Yeah!

This may make my life a LOT easier. I've been running into the exact issues you are helping fix here. Thanks for posting :)

I've been going back and forth between learning Sinatra and Node. This may seal the deal in favor of Sinatra...

I'd really like to see a comparison between Node and Sinatra::Synchrony.

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.

Good to know - I'll be starting from scratch. Any useful Sinatra resources I should use, aside from the canonical Sinatra book?

I like to start with a simple codebase: https://github.com/icco/basic

Very helpful - thanks!

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'm new to Ruby as well (getting back into programming). I'll definitely pick up Dix's book - thanks for the recommendation!

"learning Sinatra" - not much to it. Dive in!

performance benchmark using the same ab tests for node http://tjholowaychuk.com/post/543953703/express-vs-sinatra-b...

So, if I'm reading this right, response time and reqs/second look pretty comparable between this and express.

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.

(edit: improved text)

That's just plain old Sinatra.

True but you can compare the Express benchmarks to those mentioned on the Synchrony site.

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.

What rgbrgb said before you posted: you can roughly compare Express and Sinatra::Synchrony by reading the two webpages.

Also, check cyclone and a bottle clone for python goodness on this area: http://chu.pe/BZ

Is there any reason to not run this with my average Sinatra app? It seems magic and to just make stuff better?

10 kinds of awesome.

Reply on news.ycombinator.com