Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Heroku Blog: Routing Performance Update

blog.heroku.com

Post reply on HN
Print view View original

191–197 of 197 posts

Re: Heroku Blog: Routing Performance Update

#191

Post by hpguy »

latchkey wrote: post #189
Jare wrote: post #188

Earlier quoted context omitted.

> Node handles one request at a time. It isn't multithreaded. It will receive a request, process that request and return a response. If another request comes in at the same time another request is in process, it is queued until the currently processing request is finished. I'm missing something here. Node does not multithread requests, but it surely can process many requests simultaneously if these requests are waiti…

> Node does not multithread requests, but it surely can process many requests simultaneously if these requests are waiting for async operations: database, external APIs or other types of I/O usually. That's the very core idea of evented servers. Within a single request, Node can async its dealing with outside services (databases, api's, etc), but it is still only processing one request at a time. There is no 'synchro…

> Within a single request, Node can async its dealing with outside services (databases, api's, etc), but it is still only processing one request at a time. There is no 'synchronized' keyword in javascript. ;-)

This is as wrong as it can get. Multiple requests are processed "concurrently", in the sense that a request gets served as soon as an existing request awaits on async calls. It is different from thread-based concurrency and thus there is no need for things like "synchronized" keyword.

Re: Heroku Blog: Routing Performance Update

#192

Post by latchkey »

hpguy wrote: post #191
latchkey wrote: post #189

Earlier quoted context omitted.

> Node does not multithread requests, but it surely can process many requests simultaneously if these requests are waiting for async operations: database, external APIs or other types of I/O usually. That's the very core idea of evented servers. Within a single request, Node can async its dealing with outside services (databases, api's, etc), but it is still only processing one request at a time. There is no 'synchro…

> Within a single request, Node can async its dealing with outside services (databases, api's, etc), but it is still only processing one request at a time. There is no 'synchronized' keyword in javascript. ;-) This is as wrong as it can get. Multiple requests are processed "concurrently", in the sense that a request gets served as soon as an existing request awaits on async calls. It is different from thread-based co…

I think we are saying the same thing. When I say 'it is still only processing one request at a time', I'm referring to my code execution, not the async stuff or anything else within Node.

I found this to be a good explanation...

http://blog.mixu.net/2011/02/01/understanding-the-node-js-ev...

Re: Heroku Blog: Routing Performance Update

#193

Post by hpguy »

Don't know about Rails, but I'm building a MVP using Node.JS and hosting a free dyno. Can handle 250 reqs/s for dynamic requests (i.e. full stack, Postgres, Redis, Jade, Express etc.) and 1500+ reqs/s for static contents. I do use cluster with 3 workers though. Pretty happy with the result so far.

Re: Heroku Blog: Routing Performance Update

#194

Post by thenomad »

namidark wrote: post #187
thenomad wrote: post #186

Earlier quoted context omitted.

Fail fast. I can perfectly well install, set up and maintain my own Ruby servers - but it takes time. Alternatively, I can pay someone else to do that, and remove that timesink from the elapsed time between "start developing" and "find out how well we've achieved market fit". I can always optimise later - move off Heroku, develop our own load balancing, all that stuff. Once I've got a working product/market fit, I pr…

Chef/Puppet/Stackscripts/Salt/etc, and develop your own load balancing? Why on earth would you do that instead of just using HAProxy?

Misspoke - when I said "develop our own load balancing", I meant "test and pick the best existing load balancing solution, then implement that on our servers". That's as opposed to "use whatever our hosting provider offers".

Re: Heroku Blog: Routing Performance Update

#195

Post by WillieBKevin »

rdl wrote: post #175
WillieBKevin wrote: post #109

Earlier quoted context omitted.

I had a string of similar requests with Heroku between Feb 2011 and June 2012, before we migrated off their platform. I would complain about h12 errors, they would tell me to upgrade my resources and/or that it was my problem and there was nothing they can do. We ended up with a solution that was easily 10x as expensive (over-powered DB, too many dynos) as our initial configuration, and it still didn't fix the issue.…

What did you migrate to?

We're with bluebox.net and have been very happy.

Re: Heroku Blog: Routing Performance Update

#196

Post by lobster_johnson »

jlouis wrote: post #87

So to recap: Ruby on Rails is using a default configuration where each process can serve one request at a time. There is no cooperative switch (as in Node.js) or (near) preemptive switch (as in Erlang, Haskell, Go, ...). The routing infrastructure at Heroku is distributed . There are several routers and one router will queue at most one message per back-end dyno in the Bamboo stack and route randomly in the Cedar sta…

> The RoR model is very weak.

It's not "the ROR model". Rails is just an actor in the Rack space; how the framework handles feeds requests to Rails is entirely up the Rack adapter.

Rails itself is thread-safe and can handle requests concurrently with multiple threads; it can also run in a multi-process configuration.

The setup described in the article focuses on Thin, a web server that is primarily single-threaded. These days, many people use Unicorn, which uses a forking model to serve requests from concurrent processes.

Re: Heroku Blog: Routing Performance Update

#197

Post by scottschulthess »

antirez wrote: post #90

Come on startups, you should be technically skilled and able to optimize in order to spend little money . If you sum EC2 and Heroku you are going to pay like 10x what it takes to run the same machines power in a dedicated server, all this because you can't handle the operations? This is absurd IMHO. Also people that want to start a business, there is a huge opportunity here , create software that makes managing Apach…

" If you sum EC2 and Heroku you are going to pay like 10x what it takes to run the same machines power in a dedicated server, all this because you can't handle the operations? This is absurd IMHO."

It really depends. My current experience with heroku is that it is absurdly cheap - at least, for our use cases. We would have to do a lot more traffic for us to ever consider moving to a colo.

Post reply on HN