6 ms·

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

161 points by kyledrake 15y ago

kposehn 15y ago
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 :)
grandalf 15y ago
this will save heroku users serious money.
- charliesome 15y ago
  If you're running on Heroku you probably don't care about saving money...
  - tlianza 15y ago
    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.
    - charliesome 15y ago
      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)
      - maukdaddy 15y ago
        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.
        jules 15y ago
        There is a good middle ground between Heroku and setting up your own hardware: VPS hosting like Linode.
        Xylakant 15y ago
        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.
splitrocket 15y ago
10 kinds of awesome.
joshkaufman 15y ago
I've been going back and forth between learning Sinatra and Node. This may seal the deal in favor of Sinatra...
- rgbrgb 15y ago
  I'd really like to see a comparison between Node and Sinatra::Synchrony.
  - deleted 15y ago
    [deleted]
- brunoc 15y ago
  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.
  - joshkaufman 15y ago
    Good to know - I'll be starting from scratch. Any useful Sinatra resources I should use, aside from the canonical Sinatra book?
    - cloudwalking 15y ago
      I like to start with a simple codebase: https://github.com/icco/basic https://github.com/icco/basic
      - joshkaufman 15y ago
        Very helpful - thanks!
    - bigbento 15y ago
      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.
shapeshed 15y ago
performance benchmark using the same ab tests for node http://tjholowaychuk.com/post/543953703/express-vs-sinatra-benchmarks http://tjholowaychuk.com/post/543953703/express-vs-sinatra-b...
- rgbrgb 15y ago
  So, if I'm reading this right, response time and reqs/second look pretty comparable between this and express.
  - stephth 15y ago
    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 http://attractivechaos.github.com/plb Disclaimer: I use Ruby and have no experience with Node.js. (edit: improved text)
- ScottMFisher 15y ago
  That's just plain old Sinatra.
  - rgbrgb 15y ago
    True but you can compare the Express benchmarks to those mentioned on the Synchrony site.
- mrinterweb 15y ago
  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.
  - 15y ago
sciurus 15y ago
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-with-ruby-fibers http://www.igvita.com/2010/03/22/untangling-evented-code-wit...
pieter 15y ago
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.
igrigorik 15y ago
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 https://github.com/postrank-labs/goliath Same idea, em-synchrony under the hood.
tuna 15y ago
Also, check cyclone and a bottle clone for python goodness on this area: http://chu.pe/BZ http://chu.pe/BZ
tibbon 15y ago
Is there any reason to not run this with my average Sinatra app? It seems magic and to just make stuff better?

161 points by kyledrake 15y ago

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 :)

grandalf 15y ago

this will save heroku users serious money.

charliesome 15y ago
If you're running on Heroku you probably don't care about saving money...
- tlianza 15y ago
  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.
  - charliesome 15y ago
    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)
    - maukdaddy 15y ago
      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.
      - jules 15y ago
        There is a good middle ground between Heroku and setting up your own hardware: VPS hosting like Linode.
        Xylakant 15y ago
        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.

splitrocket 15y ago

10 kinds of awesome.

joshkaufman 15y ago

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

rgbrgb 15y ago
I'd really like to see a comparison between Node and Sinatra::Synchrony.
- deleted 15y ago
  [deleted]
brunoc 15y ago
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.
- joshkaufman 15y ago
  Good to know - I'll be starting from scratch. Any useful Sinatra resources I should use, aside from the canonical Sinatra book?
  - cloudwalking 15y ago
    I like to start with a simple codebase: https://github.com/icco/basic https://github.com/icco/basic
    - joshkaufman 15y ago
      Very helpful - thanks!
  - bigbento 15y ago
    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.

shapeshed 15y ago

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

rgbrgb 15y ago
So, if I'm reading this right, response time and reqs/second look pretty comparable between this and express.
- stephth 15y ago
  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 http://attractivechaos.github.com/plb Disclaimer: I use Ruby and have no experience with Node.js. (edit: improved text)
ScottMFisher 15y ago
That's just plain old Sinatra.
- rgbrgb 15y ago
  True but you can compare the Express benchmarks to those mentioned on the Synchrony site.
mrinterweb 15y ago
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.
- 15y ago

sciurus 15y ago

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-with-ruby-fibers http://www.igvita.com/2010/03/22/untangling-evented-code-wit...

pieter 15y ago

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.

igrigorik 15y ago

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 https://github.com/postrank-labs/goliath Same idea, em-synchrony under the hood.

tuna 15y ago

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

tibbon 15y ago

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