I’m working on a pretty complex Rails site (many tables, many ajaxed
controllers, etc.) that will be entering the mainstream of the
InterTubes in a few weeks.
I was wondering if any of you who have previously arrived at this
juncture could provide me with some suggestions for things to look for
and or improve in my code before I find out the hard way what does and
doesn’t work “In the real world”.
BTW, I know the question is vague. That’s because I have absolutely no
idea what to expect. Any words of wisdom from those that have already
gone through this phase of Rails development would be welcome.
thanks,
jp
(p.s. the App will be deployed on Engine Y.).
(p.p.s. Ezra, if you’re out there, is there anything in your new book
that would help me prepare for this? Or is the book all about the stuff
that you guys at EY do for me?)
i learn do test well before going live 
tests never ends…
On Aug 24, 10:33 am, Jeff P. [email protected]
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
Keith D. wrote:
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 Y… 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.
thanks,
jp
On 24-Aug-07, at 11:51 AM, Philip H. wrote:
users,
every
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
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.
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 Y… 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 
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 don’t suppose anyone tried deploying with PostGreSQL & JRuby? I keep
hearing how JRuby simplifies deployment issues as well as other problems
such as connection pooling. If MySQL clusters find joins distasteful,
maybe PostGreSQL could do a better job?
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.
I don’t suppose anyone tried deploying with PostGreSQL & JRuby? I keep
hearing how JRuby simplifies deployment issues as well as other problems
such as connection pooling. If MySQL clusters find joins distasteful,
maybe PostGreSQL could do a better job?
Not JRuby, but I’ve done a postgres app, but it’s small. Very small.
So
small it doesn’t matter
Also, for the record, my understanding is that mysql cluster can do
the
joins, it just doesn’t do them very fast all the time. particular outer
joins.
It won’t do (at least 5.0.34) queries like:
select … WHERE col1 LIKE ‘…’ OR col2 LIKE ‘…’
You have to split those into two queries and union them.
And some other little oddities like not being able to update more than
32000 rows at once, etc.
There’s a gotchas/limitations document on their site. Just be sure to
give it a really good read.
I managed to get everything loaded from memcached, except use current
logged in user.
if you use acts_as_authenticated plugin, every time you you do a
“current_user” call, it will read from DB: (User Load (0.005747)
SELECT * FROM users WHERE (users.id = 3921) LIMIT 1)
instead I save the user in memcached (==> Got User:3921 from cache.
(0.00036))
I had to change lib/authenticated_system.rb line 9
def current_user
# Without Memcached
#@current_user ||= (session[:user] &&
User.find_by_id(session[:user])) || :false
# With Memcached
@current_user ||= (session[:user] &&
User.get_cache(session[:user])) || :false
end
`
I alse started to use Partial Cache a lot,
example in list.rhtml
<% for property in @properties %>
<% cache property.permalink do %>
<%= render :partial => “each_property”, :locals=>
{:property => property} %>
<% end %>
<% end %>
lastly, i’m about to start using ESI