Rails에서layouts/application의 렌더링에 30초 이상 걸렸을 때의 체험담

Rails 3.2.13에서 일어난 일.
Rails의 layouts/application은 개발 환경(Mac OS X10.7.5Lion)에서만 예외적으로 나타나는 데 시간이 걸렸다.

rack-mini-profiler에서 측정한 결과는 다음과 같다.방송 34초.시작할 뿐만 아니라, 매번 페이지가 이동할 때마다 이상하게 시간이 걸린다.
CSS 및 JS의 컴파일링이 원인입니다.app/views/layouts/application.html.erb의,
application.html.erb

  <%= stylesheet_link_tag    "application", :media => "all" %>
  <%= javascript_include_tag "application" %>

의 섹션을 제거한 후 다시 방문하여 0.13초 안에 처리합니다.
개발 환경에서 모든 요청은 동적 컴파일됩니다.이것은 이상한 대기 시간의 원인이다.
config/environments/development.rb 설정 중
config/environments/development.rb

config.assets.compress = false
config.assets.debug = true

(초기 설정)이라 이렇게 됐다.단, 여기서 설정을 바꾸면 컴파일 전의 assets를 업데이트해도 localhost는 읽지 않습니다.가능하면 초기 설정을 유지하고 싶습니다.교활하다.
Rails4의 precompile 속도가 빠르기 때문에 앞으로 앱을 Rails4로 업데이트해 시간이 어떻게 될지 확인할 계획이다.

추기

config/environments/development.rb

config.assets.compress = true
config.assets.debug = false

다시 시작하면 본격적인 렌더링 시간이 됩니다.

뭐랄까
config/environments/development.rb

config.assets.compress = true

그리고 assets (js와 css) 를 각각 파일로 변환합니다.render) 는

<link href="/assets/application.css" media="all" rel="stylesheet" type="text/css">
<script src="/assets/application.js" type="text/javascript"></script>

되다
config/environments/development.rb

config.assets.debug = false

따라서 처음 요청할 때 assets (css와 js) 를 캐시하고, 그 다음에 캐시된 js와 css를 사용합니다.assets가 캐시되었을 때, assets를 편집하고 브라우저에서localhost에 요청을 보낼 때도 이에 반응하지 않고 업데이트되지 않습니다.따라서 assets를 편집할 때 캐시를 제거해야 합니다.내 생각엔
Asset Pipeline 문서 일본어를 번역해 준 사람이 있어서 참고하여 이해했습니다.일본어 번역: http://it.sifr.me/ruby-on-rails-asset-pipeline/