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

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 Yard).
(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?)
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

i learn do test well before going live :)

tests never ends....

On Aug 24, 10:33 am, Jeff Pritchard
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> 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 Yard).
> (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?)
> --
> Posted viahttp://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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

On 8/24/07, fred.the.master-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
<fred.the.master-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> i learn do test well before going live :)
>
> tests never ends....
>
> On Aug 24, 10:33 am, Jeff Pritchard
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
> wrote:
> > 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 Yard).
> > (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?)
> > --
> > Posted viahttp://www.ruby-forum.com/.
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Keith Davey 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 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.

thanks,
jp
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 24-Aug-07, at 11:51 AM, Philip Hallstrom wrote:
>
>> 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 :)
>
> 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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> 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 :)

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!

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> > 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.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> 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. :)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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?
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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 :)
http://revolutiononrails.blogspot.com/2007/08/advanced-rails-caching-on-edge.html


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> 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.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---