What lessons did you learn when your Rails app went "live"

i learn do test well before going live :slight_smile:

tests never ends....

I'm not sure about engine yard but one this I learned was that rails with just a fastcgi setup performs like a dog.

Deal with performance before you go live and get whatever flavour of mongrel, lighthttpd etc you like up and running.

Keith

Thanks guys for the answers so far, but these are deployment suggestions. I believe that is well in hand with the choice to go with Engine Yard. I'm talking more about the internals of the app's design and implementation.

If, for instance, anyone has discovered that certain types of ajax/prototype fanciness just killed their site once it had real users, or they found that they needed to do a certain type of thing with the database in a different way. These are the sorts of things I'm worried about right now.

Look at your ajax... it can kill you pretty quickly. At one time we cached our homepage. Great. But we needed to show the current logged in user on that page. So, an ajax call was made. Which was okay, except that this call was made in the *header* of the homepage so was on every page.

That's a lot of ajax. Doubled our page hits. So that got rewritten in javascript to look at a cookie.

It's very easy to fire off a lot of requests with ajax and Rails makes it easy to do so. And a lot of times it's useful and necessary, but make sure you're not going kill your server doing it :slight_smile:

Here I'm thinking along the lines of ensuring that you type in 3 characters or so before firing off that ajax drop down list widget, etc...

Good luck!

I think Phillip hits on a key (which leads to a deployment/infrastructure) point.

What's going wrong when it goes wrong? collect stats on performance so you can find out what went wrong.

On the-soup.net we're using SyslogLogger, rails_analyzer_tools and production_log_analzer gems to help to help sus out stinky problems that make it past our best intentions.

Cheers, Jodi

> If, for instance, anyone has discovered that certain types of > ajax/prototype fanciness just killed their site once it had real users, > or they found that they needed to do a certain type of thing with the > database in a different way. These are the sorts of things I'm worried > about right now.

Look at your ajax... it can kill you pretty quickly. At one time we cached our homepage. Great. But we needed to show the current logged in user on that page. So, an ajax call was made. Which was okay, except that this call was made in the *header* of the homepage so was on every page.

Agreed.

Look at your Ajax requests, especially if they are being called via a PeriodicUpdater.

It can kill your website very quickly. Say for example, you had a remote Ajax method being called periodically. And, say for example, that your server had a hiccup and for a brief period of time, your Ajax request was not being handled quick enough. Well, those requests start to stack up in Mongrel, waiting to be processed.

And now, your hiccup, is gotten much worse, especially if Mongrel is not able to catch up the pending Ajax requests. And now, your page is unresponsive.

So, bad things happen, if you do a lot of Ajax, without thinking hard about the consequences.

What's going wrong when it goes wrong? collect stats on performance so you can find out what went wrong.

On the-soup.net we're using SyslogLogger, rails_analyzer_tools and production_log_analzer gems to help to help sus out stinky problems that make it past our best intentions.

This reminds me of another one. Let's say you are using MySQL. And MySQL's NDB Cluster for production. And let's say you are running a lot of SQL queries that make use of a joins. MySQL Cluster doesn't really like joins. There are some queries it doesn't like *at all*. So you'll happily be coding away in development, and even do the right things and test your development code with a full set of production data. And all is well.

Until you deploy it and then that query that joined 3-4 tables (since Rails makes that easy using :include => ....) that took a fraction of a second now takes 5 seconds in production because NDB doesn't like joins.

*sigh*

Heh. :slight_smile: