My favorites | Sign in
Logo
          
New issue | Search
for
| Advanced search | Search tips
Issue 216: Improve performance of application
1 person starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  igal.koshevoy
Closed:  Jul 2008
Cc:  reidab, Mar...@reality.com, jdcohenesq, spinnerin
Type-Defect
Priority-High
Component-server
Performance


Sign in to add a comment
 
Reported by igal.koshevoy, Jun 21, 2008
The slowest pages in order of descending priority:
1. home page
2. events page
3. venues page

Because we get so much traffic to the home page and events page, these
really need some help.

The quickest solution to implement is to add file-based fragment caching to
these two pages, and observers to the events and venues models to clear
these caches. Similarly, the queries for these two pages can be delayed and
passed as lambdas to the pages so that they only run when the cache is empty.

Longer term solutions include adding cache-fu, memcache and such, but the
file-based fragment caching for just these two views will completely
address the performance issues for now.
Comment 1 by igal.koshevoy, Jun 30, 2008
Another easy win would be to add page caching to the CSS controller, see manual for
details: http://api.rubyonrails.org/classes/ActionController/Caching/Pages.html
Comment 2 by igal.koshevoy, Jul 12, 2008
Added page caching to dynamically-generated CSS. 
Cc: reidab
Comment 3 by igal.koshevoy, Jul 12, 2008
I meant to say *action* caching for the SiteController#style in that last message.
Comment 5 by igal.koshevoy, Jul 15, 2008
Reid,

I've removed your newly committed caches_page configuration and left my existing
caches_action in place for SiteController#style. Although action cache takes 1ms
rather than 0ms for page cache, the action cache doesn't write files to the "public"
directory. I don't want to have to figure out how to write an expiration mechanism at
the moment (2am), so I'd much rather stick with action caching because it stores the
rendered results in memory and still runs at ~1500 requests a second, which is fine
as far with me.

-igal
Comment 6 by reidab, Jul 15, 2008
Oops. That was the code that hadn't gotten checked in from Side Door when there was no internet access. 

I suppose in our current production situation, caches_page could be used if we deleted the cache in the 
deployment script because the CSS file will never change between deploys.
Comment 9 by igal.koshevoy, Jul 22, 2008
I believe that I've put together a sensible caching scheme for this earlier this
morning. I need to review the code and will try to commit sometime tonight.
Status: Started
Cc: Mar...@reality.com jdcohenesq spinnerin
Comment 10 by igal.koshevoy, Jul 30, 2008
I've committed and deployed these fixes. See email for further details.
Status: Fixed
Sign in to add a comment

Hosted by Google Code