[LRUG] Final lineup & registration details for February

[Neil Middleton]

Hi Makoto

On Tue, Feb 8, 2011 at 8:54 AM, Makoto Inoue <inouemak at googlemail.com>wrote:

>
> 1. What's the max request per second when you were stormed with access and
> how many dynos did you crank up at most(You showed us some graphs of
> thousands of access after the ads, was it rpm result from NewRelic or stats
> from google analytics )? I think Heroku has limit of 25 dynos per app. Is it
> sufficient to handle huge traffic?
>

At peak,we were seeing around 100 requests per second (actually a tad under,
5,6)00 per minute).  As we wanted to ensure that we never starting forming a
queue we cranked up in increments of 10 dynos, up to around 45 if I recall
correctly.  Once we were confident that we had more than enough we started
to wind down to find the 'happy place'.  As we hadn't spent any time
optimising we had a page request average of ~200ms so we knew, in theory,
that a single dyno could manage 4-5 requests / sec although in reality you
don't really get that...

The reason for wanting to avoid a queue is because having a queue gives you
two problems.  One, having to process the current requests, and clear the
queue, but also having to still process the incoming requests.

Heroku limits you to 100 dynos out of the box (the UI only takes up to 25),
but you can go for more with the CLI that Heroku provide.  Assuming that you
can get a 100ms response time, then just under 1,000 requests/second should
be doable (for five bucks an hour).  Saying that, if you talk to Heroku
support you can probably get more dynos if you need them.

2. When do you know you should crank up/down dynos. I don't think Heroku
> offer autoscaling like Google App Engine does. Did you keep monitoring
> NewRelic, or did you have some sort of monitoring system to alert you when
> certain metrics reaches some threshold?
>

There are tools coming out that allow you to autoscale, but we were doing it
manually.  Heroku really need to add this as it would be a massive help.

3. What kind of controller actions, active record queries did you find as a
> bottleneck and how did you solve (or cranking up dynos enough to ignore
> these bottlenecks)?
>

The only caching we were doing (via memcached) was page HTML fragments which
we were then building the pages up from.  Given this, the overall
performance of the app didn't really change.  The DB layer stayed nice and
fast, and the dynos were chugging away quite happily.

HTH

Neil Middleton

http://about.me/neilmiddleton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20110208/fa8dc8ef/attachment-0007.html>