Real world Rails: Rails의 캐싱(Caching) (한글)

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 영어원문  제안 및 의견 피드백

난이도 : 중급

Bruce Tate, CTO, WellGood LLC

2007 년 6 월 19 일

Ruby on Rails는 중대형 규모의, 확장성 있는 고급 애플리케이션을 위한 베이스 프레임웍으로서 각광을 받고 있습니다. Ruby는 인터프리팅(interpreted) 언어이기 때문에, 여러분의 필요에 맞게 Rails를 사용하려면 다양한 캐싱(caching) 전략들을 사용해야 합니다. 이 글에서는 여러분에게 맞는 캐싱 전략들에 대해 알아봅니다.

시리즈 소개

Rails는 개발자들 사이에서 명성이 자자하다. Rails는 많은 논쟁 거리들을 안고 있다. 누구에게 질문하는가에 따라, Rails는 매우 생산적인 언어가 되거나, 단순한 장난감이 될 수도 있다. 마케팅이 잘 되거나, 지나치게 부풀려진 것으로 판명 나기도 한다. 다른 신 기술과 마찬가지로, Rails 명성 역시 입증되지 않은 부분도 있다. C와 자바™와는 달리, Ruby는 인터프리닝 언어이고, 태생적인 성능 핸디캡을 지니고 있다.

실제로, 인터넷상의 많은 대형 사이트들은 인터프리팅 언어를 사용하고 있다. Ruby가 사용하는 것과 같은 전략(클러스터링, Shared-Nothing 아키텍처)을 사용하고 있다. 그리고 캐시(cache) 기능이 있다. 최상의 성능을 이끌어내려면 효과적인 캐싱 전략이 필요하다. Rails 개발자들은 선례를 따르기 시작했다.

Real world Rails시리즈에서는 국제적으로 유명한 저자이자 연사인 Bruce Tate가 Rails 개발의 실체를 속속들이 해부합니다. Bruce Tate는 WellGood, LLC의 CTO로서 ChangingThePresent.org를 디자인, 구현, 관리하고 있습니다. 이 사이트는 자선 기부 포털로서 다양한 방식으로 기부할 수 있습니다. 수십만 사용자들은 ChangingThePresent를 비영리 자선 단체로 인정하고 있고 그 규모와 대중성이 커지고 있습니다. Rails 애플리케이션을 구현하는 것과 관련한 수십 건의 기술자료들이 있습니다. 본 시리즈에서는 기본적인 블로그를 구현하는 기초를 넘어서, 모든 Rails 사이트가 해결해야 하는 문제들을 짚어봅니다. Rails를 최적화 하는 방법, 더욱 안정적인 사이트를 만드는 방법을 배우게 될 것입니다. 또한, 플러그인들을 추가하여 Rails의 한계를 극복하는 방법도 설명합니다. 본 시리즈의 기술자료를 읽은 후에, 실제로 Rails 사이트가 작동하는 방법을 더욱 잘 이해할 수 있을 것입니다.

시나리오

우선, ChangingThePresent.org의 사이트의 일부 페이지부터 살펴볼 것이다. 캐시가 필요한 사이트를 규명할 것이다. 그리고 나서, 이러한 페이지들을 실행하는데 사용할 코드와 전략을 설명하겠다. 특히, 다음 사항들을 집중적으로 다룰 것이다.

• 전체 정적 페이지
• 거의 변화가 없는 동적 전체 페이지
• 동적 페이지 조각
• 애플리케이션 데이터

정적 페이지를 생각해 보자. 그림 1처럼, 모든 사이트에는 사용자 동의 페이지 같은 정적 페이지가 있다. register와 user agreement를 클릭하여 그 페이지로 갈 수 있다. ChangingThePresent 의 경우, 페이지에서 모든 동적 콘텐트를 제거했기 때문에, Apache가 이를 캐싱할 수 있도록 했다. Apache 설정 규칙으로 인해 콘텐트는 Rails 서버에서 제공되지 않는다. 이러한 Rails 캐싱을 전혀 고려하지 않는다.

이제, 동적 페이지를 생각해 보자. 이론적으로는, ChangingThePresent는 동적으로 구현된 페이지들이 있지만 거의 변하지 않는다. 거의 모든 페이지들은 사용자가 로그인 했는지의 여부를 보여주기 때문에 이러한 유형의 캐싱은 우리의 관심 대상이 아니다.

페이지 조각 캐싱을 생각해 보자. 홈 페이지(그림 2)는 거의 정적이다. 몇 가지 엘리먼트만 동적이다. 매일 이 페이지는 관리자 또는 무작위로 선택된 선물 시리즈를 보여준다. "A Few of our Special Gifts for Mother's Day"라는 제목의 섹션에 있는 선물을 주목하기 바란다. 또한 맨 오른쪽에 있는 "login" 링크를 주목하라. 이 링크는 사용자가 로그인 했는지의 여부에 달려있다. 전체 페이지를 캐싱할 수 없다. 이 페이지는 하루에 한번만 변한다.

마지막으로, 애플리케이션에 대해 생각해 보자. 가장 흥미를 끄는 사이트는 동적이다. 현대적인 애플리케이션들은 레이어를 갖고 있고, 여러분은 레이어들 간 캐시를 추가할 수 있다. ChangingThePresent는 데이터베이스 레이어에 캐싱을 수행한다. 필자는 이러한 캐싱 유형들을 하나씩 검토할 것이며, ChangingThePresent에 어떻게 적용할 것인지를 볼 것이다.

정적 콘텐트의 캐싱

Mongrel은 Zed Shaw가 2500줄의 Ruby와 C로 만든 웹 서버이다. 적은 풋프린트를 가진 이 작은 서버는 Rails, Nitro, Iowa 등의 Ruby 웹 애플리케이션에 맞춘 것이다. Mongrel은 유닉스®와 리눅스™에서 실행되고, Win32에서도 실행된다. Mongrel은 프록시로서 작동하는 또 다른 웹 서버(Apache나 Litespeed)를 기반으로 실행되지만, Mongrel은 근본적으로 HTTP 서버이기 때문에 여러분이 원하는 HTTP 툴을 사용할 수 있다.

이미지를 제외하고는 정적 데이터 캐싱에 대해서는 별로 할 말이 없다. 이것은 기부 포털이기 때문에, 사용자의 감정적인 측면에 어필해야 한다. 즉 이미지와 비디오가 필요하다. 하지만, 우리의 웹 서버인 Mongrel은 정적 데이터를 잘 제공하지 않기 때문에 Apache를 사용하게 되었다.

가장 많이 사용되는 이미지를 캐시하는 이미지 가속기 Panther Express를 사용한다. 이 전략을 사용하여 서브 도메인, images.changingThePresent.org를 만들 것이다. Panther Express는 로컬 캐시에 모든 이미지들을 직접 제공하고 요청을 보낸다. Panther 서비스는 언제 우리가 이미지를 수정하는지를 모르기 때문에 다음과 같이 HTTP 헤더를 통해 알려준다.

                
HTTP/1.1 200 OK
Cache-Control: max-age=86400, must-revalidate
Expires: Tues, 17 Apr 2007 11:43:51 GMT
Last-Modified: Mon, 16 Apr 2007 11:43:51 GMT

이들은 HTML 헤더가 아니다. 웹 페이지 콘텐트와는 별개로 구현된다. 여러분의 웹 서버에서는 이러한 HTTP 헤더들이 구현될 것이다. 웹 서버 설정 부분은 이 글에서는 별로 소용이 없으므로, Rails 프레임웍에서 관리되는 캐시 콘텐트로 주제를 옮겨가 보도록 하자. (참고자료)

페이지 캐싱

아주 가끔씩만 변하는 동적 페이지가 있다면, 페이지-레벨 캐싱을 사용해야 할 것이다. 블로그와 공용 게시판이 이러한 애플리케이션의 대표적인 예이다. 페이지 캐싱을 사용하면, Rails에서 동적 HTML 페이지를 구현할 수 있고 공개 디렉토리에 이를 저장할 수 있기 때문에, 애플리케이션 서버는 다른 정적 페이지처럼 제공할 수 있다.

Rails는 페이지가 캐싱 된다면 그림을 입력하지 않기 때문에 페이지 캐싱은 Rails에서 가장 빠른 캐싱 유형이다. 가장 기본적인 레벨에서, 페이지 캐싱은 Rails에서 가장 수행하기 쉽다. 페이지 캐싱과 조각 캐싱 모두 컨트롤러 레벨에서 발생한다. Rails에게 다음을 명령해야 한다.

• 어떤 페이지를 캐싱 할 것인가?
• 페이지 콘텐트가 변할 때 캐시에서 페이지들을 어떻게 종료시킬 것인가?

컨트롤러 클래스 내에 caches_page 명령어를 사용하여 페이지 캐싱을 실행한다. 예를 들어, about_us_controller에서 privacy_policy와 user_agreement 페이지를 캐싱하려면 아래 코드를 입력한다.

                
class AboutController < ApplicationController
  caches_page :privacy_policy, :user_agreement 
end

expire_page 명령어를 사용하여 페이지들을 종료시킬 수 있다. Rails가 new_pages 액션을 호출할 때 위 페이지들을 종료하려면 다음 코드를 사용한다.

                
class AboutController < ApplicationController
  caches_page :privacy_policy, :user_agreement 
  
  def new_pages
    expire_page :action => :privacy_policy
    expire_page :action => :user_agreement
  end
  
end

URL 같은 소소한 문제들도 신경 써야 한다. 여러분의 URL은 URL 매개변수에 의존하지 않는다. 예를 들어, gifts/water?page=1 대신, gifts/water/1을 사용해야 한다. routes.rb에서 이 같은 URL을 쉽게 사용할 수 있다. 예를 들어, 우리 페이지들은 어떤 탭이 선택되었는지를 보여주는 탭 매개변수를 갖고 있다. URL의 탭 부분을 만들려면 다음과 같은 라우팅 규칙이 필요하다.

                
map.connect 'member/:id/:tab', :controller => 'profiles', :action => 'show'

페이지 매개변수를 가진 리스팅과 URL 매개변수에 의존하는 다른 페이지에도 같은 작업을 해야 한다. 보안 문제도 고려해야 한다.

페이지가 캐시에 있다면 Rails 프레임웍은 개입되지 않기 때문에 서버는 보안을 관리할 수 없다. 사용자가 페이지를 볼 수 있는 권한이 있든 없든, 웹 서버는 캐시에 있는 어떤 페이지라도 실행한다. 따라서, 페이지 보기에 제한을 두고 싶다면 페이지 캐싱을 사용해서는 안된다.

지금까지는 단순히 간단한 정적 페이지를 캐싱할 때의 이야기였다. 콘텐트가 단순하다면 쉽게 할 수 있다.

보다 복잡한 콘텐트를 캐싱할 때는 이야기가 달라진다. 더욱 동적인 페이지를 캐싱하기 때문에 종료 로직이 더 복잡해진다. 복잡한 종료 정책들을 처리하려면 커스텀 스위퍼(sweeper)를 작성 및 설정해야 한다. 이 클래스들은 특정 컨트롤러 액션이 종료되면 캐시에서 선택된 엘리먼트를 삭제한다.

대부분의 커스텀 스위퍼들은 일부 모델 객체를 관찰하고, 그 변경 사항에 기반하여 한 개 이상의 캐시 페이지를 종료하기 위해 로직을 종료한다. Listing 5는 전형적인 캐시 스위퍼이다. 이 스위퍼에서 개발자는 after_save 같은 레코드 이벤트를 정의할 수 있다. 이 이벤트가 종료하면 스위퍼가 종료되고 그 캐시에서 선택된 페이지들을 무효로 할 수 있다. 이 예제는 expire_page 메소드를 기반으로 한 무효화를 보여주고 있다. 많은 중요한 애플리케이션들은 Ruby의 뛰어난 파일 시스템 유틸리티를 직접 사용하여 캐싱된 페이지들을 삭제한다.

                
class CauseController < ApplicationController
   cache_sweeper :cause_sweeper
...

class CauseSweeper < ActionController::Caching::Sweeper
  observe Cause
    
  def after_save(record)
    expire_page(:controller => 'causes', :action => 'show', 
               :id => record.id)
    cause.nonprofits.each do |nonprofit|
     expire_page(:controller => 'nonprofits', :action => 'show', 
                  :id => nonprofit.id)
     end
   end
end

여러분은 아마도 페이지 캐싱의 단점을 생각할 수도 있다. 바로 복잡성이다. 페이지 레벨 캐싱은 잘 수행할 수 있지만 근본적인 복잡함 때문에 애플리케이션을 테스트 하기 어렵고, 시스템에 버그가 생길 가능성도 높아진다. 또한, 페이지가 각 사용자마다 다르거나, 인증을 받은 페이지만 캐싱하기 원한다면 페이지 캐싱 그 이상을 생각해야 한다. ChangingThePresent의 경우, 사용자가 로그인을 했는지의 여부에 따라 기본 레이아웃에 대한 링크를 바꾸기 때문에 두 상황 모두를 다루어야 한다. 대부분의 페이지에 페이지 레벨 캐싱을 고려할 수도 없다. 참고자료 섹션에 페이지 레벨 캐싱을 다룬 기술자료들을 소개해 놓았다. 이제 전체 페이지(whole-page) 캐싱의 또 다른 형태인 액션 캐싱에 대해 생각해 보자.

액션 캐싱(Action caching)

지금까지 페이지 캐싱의 장점과 단점을 배웠다. 페이지 검색을 위해 Rails는 그림을 집어넣지 않는다. 장점은 속도이다. 단점은 유연성이다. 이 애플리케이션의 조건(예를 들어, 인증)에 기반하여 전체 페이지 캐싱을 해야 한다면 액션 캐싱(Action caching)을 사용할 수 있다.

액션 캐싱은 페이지 캐싱처럼 작동하지만 흐름은 약간 다르다. Rails는 액션을 실행하기 전에 컨트롤러를 호출한다. 이 액션에 의해 실행된 페이지가 이미 캐시에 있다면, Rails는 이를 다시 제공하기 보다는 캐시에 있는 페이지를 제공한다. 이러한 상황에서는 페이지 캐싱 보다는 약간 느리지만 장점도 있다. 거의 모든 Rails 인증 스킴은 컨트롤러에서 필터링 전에 사용하는 것으로 짜인다. 액션 캐싱은 컨트롤러에서 인증과 필터를 활용할 수 있다.

액션 캐싱은 의미적으로 볼 때 페이지 캐싱과 거의 흡사하게 작동하지만, 다른 명령어를 갖고 있다. Listing 6은 caches_action 명령을 사용하는 방법이다.

                
    class AboutController < ApplicationController
      caches_action :secret_page, :secret_list 
    end

캐시 종료와 스위퍼는 동일한 방식으로 작동한다. 페이지 캐싱을 사용하지 않는 것과 같은 이유로 액션 캐싱을 사용하지 않지만, 조각 캐싱(fragment caching)은 훨씬 더 중요하다.

페이지 조각 캐싱하기

부분 캐싱을 사용하면, 페이지의 일부를 캐싱할 수 있고, 가끔 레이아웃을 위한 콘텐트를 캐싱할 수 있다. 조각 캐싱을 사용하면, 개발자들은 웹 페이지 상에 직접 배치된 rhtml 명령어 블록을 만들어서 캐싱 할 조각들을 구분한다. (Listing 7) ChangingThePresent.org에서, 우리는 조각 캐싱을 사용하여 프론트 페이지와 여러 다른 페이지들을 캐싱한다. 이 모든 페이지들은 데이터베이스 중심의 액세스 방식을 갖고 있고 가장 대표적인 페이지들이다.

                
<% cache 'gifts_index' do %>
    <h3>
      Here, you can make the world a better place with a single gift. Donation gifts 
      are also a wonderful way to honor friends and family. Just imagine what we
      can achieve together.
    </h3>
    <h2 class="lightBlue"><%= @event_title %></h2>
    <div id="homefeatureitems">
        <% for gift in @event_gifts %>
          <%= render :partial => 'gifts/listable', :locals => { :gift => gift } %>
        <% end %>
    </div>
    ...
<% end %>

Listing 7에서, cache 헬퍼는 캐싱 할 조각을 구분한다. 첫 번째 매개변수는 캐시 조각을 구분하는 고유 이름이다. 두 번째 매개변수에는 코드 블록(첫 번째 do와 마지막 end 사이)이 포함되어 있고, 캐싱 할 RHTML 조각들을 정확히 구분하고 있다.

우리 사이트에는 단 하나의 홈 페이지가 있기 때문에 페이지 네이밍은 쉽다. 다른 경우, 캐시 조각을 고유하게 구분하기 위해 페이지용 URL을 결정하는 메소드를 사용한다. 예를 들어, 세계 평화나 빈민 구제 같은 주제에 대한 코드를 캐싱할 때 Listing 8의 코드를 사용한다. 이 코드는 permalink라고도 하는 permanent url을 찾는다.

                
<% cache @cause.permalink(params[:id]) do %>

일반적으로, 개별 페이지들을 캐싱할 때, 스위퍼로 이들을 종료해야 한다. 가끔씩, 간단한 시간 기반의 객체 종료를 사용하는 것이 더 쉽고 깔끔하다. 기본적으로, Rails에는 이 같은 장치가 없지만, timed_fragment_cache라고 하는 플러그인이 이를 수행한다. 이 플러그인을 사용하여, 캐싱 된 콘텐트 또는 페이지용 동적 데이터를 제공하는 컨트롤러 코드에서 타임아웃을 지정할 수 있다. 예를 들어, Listing 9는 주제 리스트가 있는 페이지용 동적 데이터를 구현하는 코드이다. when_fragment_expired 메소드는 연결된 캐시 조각이 종료할 때만 실행된다. 이 메소드는 매개변수를 취하고, 타임아웃의 길이, 코드 블록, 콘텐트가 종료할 때 재구현 할 콘텐트를 지정한다. 또한 rhtml 페이지 내에서 타임아웃을 캐시 메소드와 함께 지정할 수 있지만 우리는 컨트롤러 기반 방식을 사용했다.

                
def index
  when_fragment_expired 'causes_list', 15.minutes.from_now do 
    @causes = Cause.find_all_ordered
  end
end

시간 기반 종료 기술을 사용하면 약간 오염된 데이터도 능히 거둘 수 있다면 캐싱 전략을 상당히 단순화 할 수 있다. 캐싱된 엘리먼트의 경우, 캐싱하고자 하는 콘텐트, 동적 콘텐트를 만들어 내는 컨트롤러 액션, 타임아웃만 지정하면 된다. 페이지 캐싱과 마찬가지로, expire_fragment :controller => controller, :action => action, :id => id 메소드를 사용하여 콘텐트를 명확히 종료할 수 있다. 이 메소드는 캐싱된 액션과 페이지의 종료와 비슷하게 작동한다. 이제는 백엔드를 설정하는 방법을 배워보자.

Memcached

지금까지, Ruby on Rails용 페이지 및 조각 캐싱 모델에 대해 설명했다. 이제는 캐싱된 데이터가 어디로 가야 하는지를 정의할 차례이다. 기본적으로, Rails는 캐싱된 페이지들을 파일 시스템에 둔다. 캐싱된 페이지와 액션들은 퍼블릭 디렉토리로 간다. 캐싱된 조각들을 위한 스토리지 위치를 설정할 수 있다. 메모리 스토어, 파일 시스템(디렉토리), 데이터베이스, memcached라고 하는 서비스를 사용할 수 있다. ChangingThePresent.org는 memcached를 사용한다.

Memcached를 네트워크를 통해 접근할 수 있는 거대한 해시 맵(hash map)으로 생각하라. 메모리 기반 캐싱은 빠르고, 네트워크 기반 캐시는 확장성이 있다. 플러그인 지원을 통해, Rails는 조각 캐싱에 memcached와 ActiveRecord 모델을 사용할 수 있다. 이를 사용하려면, memcached를 설치하고(참고자료) environment.rb (또는 production.rb 같은 환경 설정 파일들 중 하나)에서 이를 설정한다.

                
config.action_controller.perform_caching = true

memcache_options = {
  :c_threshold => 10_000,
  :compression => false,
  :debug => false,
  :readonly => false,
  :urlencode => false,
  :ttl => 300,
  :namespace => 'igprod',
  :disabled => false
}

CACHE = MemCache.new memcache_options

Listing 10은 전형적인 설정 방법이다. 첫 번째 라인 config.action_controller.perform_caching = true는 캐싱을 시작한다. 다음 라인은 캐싱 옵션을 준비한다. 디버깅 데이터를 얻고, 캐싱을 작동하지 않게 하고 캐시의 네임스페이스를 정의할 수 있도록 하는 다양한 옵션들이 있다. 참고자료 섹션에서 memcached와 관련한 설정 옵션들을 참고하기 바란다.

모델 캐싱하기

마지막 캐싱 형태는 모델 기반 캐싱이다. 우리는 CachedModel이라고 하는 커스텀 캐싱 플러그인을 사용한다. 모델 캐싱은 데이터베이스 캐시의 제한된 형태이다. 이 캐시는 모델 별로 실행하기 쉽다.

이러한 캐싱 솔루션을 사용하려면 ActiveRecord를 확장하는 대신 CachedModel 클래스를 확장한다. CachedModel은 ActiveRecord::Base를 확장한다. ActiveRecord는 완전한 객체 관계형 매핑 레이어는 아니다. 이 프레임웍은 복잡한 기능을 수행할 때 SQL에 많이 의존하고, 사용자는 원하는 대로 SQL을 쉽게 사용할 수 있다. SQL을 직접 사용하면 캐싱은 문제가 많아진다. 캐싱 레이어는 단일 데이터베이스 행 보다는 전체 결과 세트를 처리해야 하기 때문이다. 전체 결과 세트를 핸들링 하면 문제가 많이 생기고, 애플리케이션 로직의 지원 없이는 거의 불가능 하다. 이 같은 이유로, CachedModel의 포커스는 단일 모델 객체의 캐싱에 있고, 단일 행을 리턴하는 쿼리의 속도를 높일 뿐이다.

                
Class Cause < CachedModel

대부분의 Rails 애플리케이션들은 사용자 객체 같은 여러 아이템에 반복적으로 액세스 한다. 이 같은 상황에서 모델 캐싱은 속도를 높이기에 알맞다. 우리는 이제야 ChangingThePresent에 모델 기반 캐싱을 사용하기 시작했다.

맺음말

Ruby는 매우 생산적인 언어이지만, 인터프리팅 언어라는 태생적 한계로 성능 면에서는 이상적이지 않다. 대부분의 메이저 Rails 애플리케이션들은 캐싱을 효과적으로 사용하여 이러한 한계를 극복한다. ChangingThePresent.org에서는 주로 조각 캐싱을 사용하고 있고, 시간 기반 메소드를 사용하여 컨트롤러에서 캐싱 조각들을 종료한다. 사용자 로그인에 따라 변경되는 페이지가 있음에도, 이러한 방식이 우리에게는 잘 맞았다.

memcached 기반 CachedModel 클래스 사용에 대해서도 공부했다. 우리는 캐싱이 데이터베이스 성능에 미치는 영향도 연구했는데, 그 결과는 상당히 긍정적이다. 다음 글에서는, 데이터베이스 최적화를 수행하는 방법을 설명하도록 하겠다.

참고자료

• Java To Ruby: Things Your Manager Should Know (Pragmatic Bookshelf, 2006): 자바에서 Ruby on Rails로 전향하기.
  
  
• Changing The Present: 비영리 인터넷 장터
  
  
• "Rolling with Ruby on Rails", Learn all about Ruby on Rails: 설치 과정을 비롯한 Ruby와 Rails와 관련한 모든 것.
  
  
• Active Record: Ruby on Rails의 영속성 프레임웍.
  
  
• Rails Caching: 페이지 캐싱, 액션 캐싱, 조각 캐싱 등 Rails의 캐싱 모델 연구.
  
  
• Ruby on Rails Caching Tutorial: Gregg Pollack 제공 튜토리얼, 캐시 스위핑 전략 개요.
  
  

• Ruby on Rails: 오픈 소스 Ruby on Rails 웹 프레임웍 다운로드.
  
  
• Mongrel: 고급 Rails 사이트를 실행하는 애플리케이션 서버. ChangingThePresent.org에서 Mongrel을 사용하고 있다.
  
  
• Apache Web server: 정적 콘텐트를 제공하는 웹 서버.
  
  
• Panther Express: ChangingThePresent.org에서 이미지 콘텐트 캐시에 사용하고 있다.
  
  
• Timed-cache expiration plug-in: Richard Livsey이 만든 플러그인. 캐시 조각들의 종료 시간을 핸들한다. ChangingThePresent.org 사이트에서는 이 플러그인을 사용하여 홈페이지와 다른 주요 캐시 조각들을 캐싱하고 있다.
  
  
• Memcached: 분산 객체 캐시를 제공하는 네트워크 서비스. ChangingThePresent 캐싱 서비스의 백엔드이다.
  
  
• CachedModel: ActiveRecord 객체를 지원하는 memcached 캐싱 서비스. CachedModel은 단일 행 결과를 통해 데이터베이스 쿼리를 가속화 한다.

필자소개

		Bruce Tate는 베스트 셀러인 Jolt winner Better, Faster, Lighter Java의 저자이다. 최근에는 From Java to Ruby and Rails: Up and Running를 출간했다. IBM에서 13년 동안 근무했으며, 자바와 Ruby on Rails에 기반한 경량 개발 전략과 아키텍트를 전문적으로 다루는 RapidRed를 창립했다. 현재 Rails 개발자들과 함께 ChangingThePresent.org를 개발 중이다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

이 문서 북마킹 하기 mar.gar.in naver eolin del.icio.us

위로