[LRUG] Final lineup & registration details for February

[Neil Middleton]

As Glenn said, A) would be the preference.

Think of a dyno as a single request, so your page would create one request,
and your AJAX call another, so you'd need the two dynos to be able to handle
that page request.  Ideally though (and assuming you can) you run the
external calls in a way that you can cache them using the Memcached or Redis
add-ons so that you're not running 'hot' all the time.

Saying this, none of the above are Heroku specific problems that you need to
solve as I'm pretty sure you'd see these same architecture issues on any
platform.

If people are interested, I'd be happy to do a proper sized talk on Heroku
at some point in the future and how it all works in more detail.

Neil

On Tue, Feb 8, 2011 at 1:34 PM, Glenn Gillen <glenn at rubypond.com> wrote:

> A: respond quickly by putting the external API call to backgroundjob, and
> check the response via ajax periodically (could use commet or websocket
> alternatively).
>
>
> +1
>
> B: separate this long running request to different component (eg: node.js
> on heroku or other PAAS) and call this via cross domain ajax call.
>
>
> You can't sign up for a node.js account on Heroku any more :(
>
> C: Don't use Heroku. Heroku is not meant for that kind of purpose.
>
>
> That's an option. But you're going to have a similar problem wherever you
> take an app like this. If you're sticking with a ruby stack, I'd opt for
> option A). If you're keeping it on Heroku, then you'd need to pay for a
> worker to pick-up the jobs. While I don't know the exact figures, I suspect
> that if you tried to fix it by increasing the number of dynos to hide the
> latency from concurrent users you'd need to scale dynos up quicker than
> you'd have to scale workers.
>
> It's still early days, but I think this library is looking promising for
> doing job management in a simple and sensible fashion:
> https://github.com/ryandotsmith/Queue-Classic
>
> Glen
>
>
>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>


-- 
Neil Middleton

http://about.me/neilmiddleton
The internet's most comprehensive source for all things Neil Middleton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20110208/fe4f5c81/attachment.html>