AFAIK Passenger does have a similar concept with running processes (having a default of six running processes, which are comparable to 6 dynos).
The situation you describe should have the same results on Passenger as Heroku. More info on Passenger here: http://www.modrails.com/documentation/Users%20guide%20Apache.html#_resource_control_and_optimization_options Neil Middleton http://about.me/neilmiddleton On Wednesday, 16 February 2011 at 17:29, Tim W wrote: > I guess I am just used to using passenger which uses a global queue, > making a single long running request a non issue. > > > > On Feb 16, 11:57 am, Neil Middleton <[email protected]> wrote: > > Is it, but you have a healthy dyno. If the dyno crashes, or hangs somehow, > > it gets removed. > > > > Neil Middletonhttp://about.me/neilmiddleton > > > > > > > > > > > > > > > > On Wednesday, 16 February 2011 at 16:55, Tim W wrote: > > > Thanks, I will give rack-timeout a try. > > > > > So what it seems like is that the routing mesh is not as sophisticated > > > as Heroku leads on? > > > > > On Feb 16, 11:45 am, Neil Middleton <[email protected]> wrote: > > > > The dyno is still running the long request, successfully. It's only the > > > > routing mesh that's returned the timeout error back to the user. > > > > Therefore, the dynos still in your 'grid' and ready for new requests. > > > > > > I blogged about something very similar a couple of weeks > > > > back:http://neilmiddleton.com/avoiding-zombie-dynos-with-heroku > > > > > > Neil Middletonhttp://about.me/neilmiddleton > > > > > > On Wednesday, 16 February 2011 at 16:42, Tim W wrote: > > > > > The Heroku website claims: > > > > > > > http://heroku.com/how/dyno_grid_last#3 > > > > > "If a dyno is unresponsive for any reason (user bugs, long requests, > > > > > or high load), other requests will be routed around it." > > > > > > > In my experience, this does not seem to be the case. We have several > > > > > admin features in our app that when requested with certain params, it > > > > > can take longer then 30s to run. (I am working on ways to get these in > > > > > check and in the background). When a user trips one of these long > > > > > running requests, Heroku appears to queue additional requests to this > > > > > dyno and those requests time out, even though there are plenty of > > > > > other dynos available to handle that request. > > > > > > > Is the statement on the Heroku website true or false? It does not > > > > > appear that Heroku actively monitors the dynos to see if they are busy > > > > > with a long running request. Is there a better way to handle this > > > > > situation? > > > > > > > Thanks.. > > > > > -tim > > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > > > > Groups "Heroku" group. > > > > > To post to this group, send email to [email protected]. > > > > > To unsubscribe from this group, send email to > > > > > [email protected]. > > > > > For more options, visit this group > > > > > athttp://groups.google.com/group/heroku?hl=en. > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Heroku" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]. > > > For more options, visit this group > > > athttp://groups.google.com/group/heroku?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Heroku" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/heroku?hl=en. > -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
