2011-02-14 9 views
5

Tengo una gran vista, que tarda mucho tiempo en terminar de representar el contenido. ¿Cuál es el mejor método para crear perfiles, qué parte de la vista toma más tiempo? He leído sobre ruby-prof, pero no estoy seguro de dónde ubicarlo, para perfilar el renderizado de la vista. Si existen otras opciones, quiero conocerlas también.Vista de perfil en Rails

+2

los registros indican cuánto tarda cada parcial en renderizar. Puede dividir su vista para verificar. – apneadiving

Respuesta

0

Si no lo hizo, consulte primero la carpeta log en la carpeta de la aplicación. Contiene archivos de registro para cada entorno de su aplicación.

Con el fin de perfilar una aplicación rieles, ponga sus pruebas a la carpeta your_app/test/profile

http://ruby-prof.rubyforge.org/

+2

Esto no proporciona información acerca de qué parte de la vista toma más tiempo, y env/logs de la aplicación solo da tiempos difíciles, por ejemplo, cuánto tiempo tomó un parcial para representar. – astropanic

1

NewRelic y los registros son útiles, pero a veces se necesitan más. NewRelic tiene una herramienta gratuita que puede ayudarlo a cavar localmente, y herramientas como ruby-prof le brindarán información, pero puede ser difícil saber qué hacer con ella.

Encontré una página de registro en la aplicación de un cliente que era ridículamente lenta, sin motivo aparente. Los registros confirmaron que fue lento, y que la lentitud no se debió a la DB, pero no me ayudó a ver cuál era el problema.

https://github.com/brynary/rack-bug/

es más fácil de usar que ruby-prof, y se puede activar/desactivar rápidamente cuando se necesita para sumergirse en algo. Lo uso todo el tiempo cuando ayudo a las personas a ajustar sus aplicaciones de Rails. Me ayudó a entender qué parcial era lento, y con un poco de prueba y error, descubrí que era el menú desplegable para zonas horarias en la página de registro

En una página estaba (la versión lenta): <% = time_zone_select: usuario,:. time_zone, tzinfo :: Country.get ("US") zonas, {}%>

y otro fue: <% = f.time_zone_select: TIME_ZONE, ActiveSupport :: TimeZone.us_zones, : predeterminado => "Hora del Pacífico (EE. UU. & Canadá)"%>

Mis números de antes/después:

orig template render   1392.91 
fixed template render   165.56 
fixed on REE instead of 1.8.7 100.70 

No profundicé más, ya que tenía otros problemas que corregir, pero sería posible almacenar en caché las zonas horarias y obtener una respuesta aún más rápida.

+1

¿cómo terminaste arreglando esto? Estamos viendo lo mismo: hay 4 páginas en nuestra aplicación que procesan zonas horarias (solo en EE. UU.) Y, de manera consistente, tardan más de 1200ms en renderizarse. Saca la línea y es como 140ms en total. –

+0

Acabo de usar ActiveSupport :: TimeZone.us_zones en lugar de zonas TZInfo :: Country.get ("EE. UU.). –

+1

Impar: en realidad estábamos usando ActiveSupport :: TimeZone.us_zones. Por si fuera poco, esto podría ayudar, de hecho agregamos un inicializador a la aplicación para cargar las zonas horarias, simplemente configúralo como una variable local. Lo que encontramos es que la primera llamada para cargar las zonas horarias tomó para siempre, pero después de eso fueron ágiles. Por lo tanto, agregar la llamada al inicializador solucionó el problema para nosotros: toma un segundo extra para cargar la aplicación, pero no afecta el rendimiento. –

3

Es bastante fácil, en realidad. Acabo de encontrar y solucionó un problema de rendimiento con una plantilla HAML usando ruby-prof. La parte pertinente de la plantilla se veía algo así como:

- @collection.each do |x| 
    = render :partial => 'name', :locals => {:object => x} 

Me aseguré ruby-prof fue en el Gemfile y temporalmente cambió eso a:

- require 'ruby-prof' 
    - RubyProf.start 
    - @collection.each do |x| 
    = render :partial => 'name', :locals => {:object => x} 
    - result = RubyProf.stop 
    - printer = RubyProf::CallStackPrinter.new(result) 
    - file = File.open('profile.html', 'w') 
    - printer.print(file) 
    - file.close 

continuación, arranque la aplicación, golpeó la página un par de veces y abra el recién creado profile.html en mi navegador para ver qué parte estaba causando el problema.

+0

gracias por esto - Me quedé atrapado con un problema de visión lenta, e hice exactamente esto para encontrar mi problema. FWIW: mi problema era una tabla de entradas con una columna que podría editarse utilizando best_in_place. ¡Resulta que tener un campo de bip con una gran lista de opciones para cada fila no se renderiza tan rápido! –

8

La manera más fácil de llegar rápidamente al cuello de botella es utilizando el modo NewRelics Developer que funciona localmente.

  1. Asegúrese de que tiene ruby-prof y newrelic_rpm en su Gemfile.
  2. Vaya a localhost:3000/newrelic y empezar de perfiles (en la barra de la derecha)
  3. Hacer una solicitud real a la página de la aplicación que quiere medir, posiblemente varias veces para asegurarse de que no se mide alguna almacenamiento en caché & cosas.
  4. Navegue de regreso al modo de desarrollador newrelic, seleccione el seguimiento de solicitud.
  5. Ordene la tabla por la columna "self". Esto es crucial ya que la clasificación predeterminada por tiempo total es engañosa.
  6. Mire en las 10 principales llamadas, cómo se llaman y es probable que encuentre el cuello de botella.

Descargo de responsabilidad: He introducido esta función de clasificación en el modo de desarrollador de newrelic, por lo que soy parcial. Sin embargo, inténtalo si mismo.

Cuestiones relacionadas