As Glenn said, A) would be the preference.  <div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>Neil<br><br><div class="gmail_quote">On Tue, Feb 8, 2011 at 1:34 PM, Glenn Gillen <span dir="ltr"><<a href="mailto:glenn@rubypond.com">glenn@rubypond.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><div>A: respond quickly by putting the external API call to backgroundjob, and check the response via ajax periodically (could use commet or websocket alternatively).</div>
</blockquote><div><br></div></div><div>+1</div><div class="im"><br><blockquote type="cite">
<div>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.</div></blockquote><div><br></div></div><div>You can't sign up for a node.js account on Heroku any more :(</div>
<div class="im"><br><blockquote type="cite"><div>C: Don't use Heroku. Heroku is not meant for that kind of purpose.</div>
</blockquote><br></div></div><div>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.</div>
<div><br></div><div>It's still early days, but I think this library is looking promising for doing job management in a simple and sensible fashion:</div><div><a href="https://github.com/ryandotsmith/Queue-Classic" target="_blank">https://github.com/ryandotsmith/Queue-Classic</a></div>
<div><br></div><div>Glen</div><div><br></div><div><br></div><br></div><br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div>Neil Middleton</div><div><br></div><div><a href="http://about.me/neilmiddleton" target="_blank">http://about.me/neilmiddleton</a></div><div>The internet's most comprehensive source for all things Neil Middleton</div>
<br>
</div>