Solución:
Estaré de acuerdo con todos los demás. Tienes que perfilar. No tiene sentido hacer nada con su código hasta que sepa qué está causando específicamente la lentitud. Tratar de solucionar un problema sin comprender la causa es como sentirse enfermo y decidir someterse a muchas cirugías hasta que se sienta mejor. Primero diagnostique su problema. Podría ser algo pequeño como una configuración de red o podría ser una línea incorrecta en su código.
Algunos consejos para la elaboración de perfiles:
Cómo perfilar su aplicación de rieles
Aplicaciones de rieles de prueba de rendimiento
At the Forge – Aplicaciones de perfiles de rieles
Una vez que haya encontrado el cuello de botella, puede averiguar qué hacer.
Recomiendo estos videos: Railslab Scaling Rails
Revisado ahora según los resultados de los profesionales:
está bien. Ahora que puede ver que su problema es que está haciendo algún tipo de cálculo utilizando una consulta basada en recorrer los resultados de otra consulta de registro activo, le aconsejaría que busque construir una declaración SQL personalizada que combine sus criterios de selección inicial y el cálculo de bucle para obtener lo que necesita. Definitivamente puede acelerar esto optimizando el SQL.
¿Cuántas de esas consultas de 0-10 ms se están ejecutando por acceso a la vista? ¿A qué partes de su modelo de datos se hace referencia? ¿Está utilizando: include para obtener una carga entusiasta en sus asociaciones?
Rails es tan lento como tú lo haces. Con la comprensión viene la velocidad (¡por lo general!)
Ampliando lo anterior, ¿tiene has_many asociaciones en las que, en particular, tu vista hace referencia al lado “muchos” sin un :include? Esto hace que tu find(:all) en la tabla maestra para que se ejecute con una combinación del detalle; si tiene una gran cantidad de registros de detalle y los está procesando todos individualmente, esto puede resultar costoso.
Algo como esto:
Master.find(:all, :include => :details)
…podría ayudar. Sin embargo, sigo adivinando a partir de información escasa.
Aquí hay un viejo Railscast sobre el tema.
Si bien RnR tiene la reputación de ser lento, esto suena demasiado extremo para ser un simple problema con el idioma.
Debe ejecutar un generador de perfiles para determinar exactamente qué funciones son lentas y por qué. Lo más común que ralentiza una aplicación web es el “problema n + 1”. Es decir, cuando tiene n elementos de datos en su base de datos, la aplicación realiza n consultas separadas a la base de datos en lugar de realizar una consulta que las obtiene. Pero no puedes saber hasta que ejecute el generador de perfiles. ruby-prof es un generador de perfiles que he usado.
Editar según los resultados del perfil editar:
Creo firmemente que puedes siempre eliminar un bucle de consulta. Como dice Mike Woodhouse, la forma de Rails para hacer esto es especificar las relaciones entre sus tablas con un tiene muchos u otra asociación y luego dejar que los rieles generen automáticamente la unión de la tabla, esto es claro, rápido y “al estilo Rails”. Pero si está comenzando con SQL puro o si las asociaciones no funcionan en este caso, simplemente puede generar las combinaciones apropiadas usted mismo. Y si todo lo demás falla, puede crear una vista o una tabla desnormalizada que contenga los resultados que se encontraron anteriormente a través de un bucle. De hecho, el hecho de que tenga que iterar a través de consultas generadas podría sea una señal de que el diseño de su mesa tiene algunos defectos.
Dicho todo esto, si el almacenamiento en caché de los resultados de la consulta funciona lo suficientemente bien para usted, continúe con él. Optimice cuando sea necesario.