ruby on rails - Extraño TTFB(tiempo al primer byte) problema en Heroku
heroku dashboard login (2)
Resultó que era una especie de cola de solicitudes. A veces, ese servidor web estaba ocupado, y como heroku acaba de robar aleatoriamente las solicitudes entrantes al azar a cualquier banco de pruebas, entonces podría terminar en una cola detrás de un banco de pruebas, que estaba totalmente bloqueado debido, por ejemplo, a problemas en la base de datos. Lo extraño es que esto apenas se notó en la nueva reliquia (es una buena idea desmarcar todos los demás recursos cuando se visualiza thin en sus gráficos, luego aparece repentinamente la cola)
EDIT 21/2 2013: ¡Resultó que la razón por la que no era apenas perceptible en Newrelic era que no se midió! http://rapgenius.com/Lemon-money-trees-rap-genius-response-to-heroku-lyrics
Nos parece muy frustrante, y terminamos dejando a Heroku a favor de servidores dedicados. Esto nos dio un rendimiento 20 veces mejor a un 1/10 del costo. Además, debo decir que Heroku está decepcionado porque, en el momento en que sucedió esto, negó que la lentitud se debiera a su infraestructura, a pesar de que sospechábamos de ella y la destacó varias veces. Incluso obtuvimos respuestas como esta:
Heroku 28/8 2012: "Si no está viendo colas de solicitudes u otras lentitudes reportadas en New Relic, entonces esto probablemente no sea un problema del lado del servidor. El enrutamiento interno de Heroku debería tomar <1ms. Ninguno de nuestros sistemas de monitoreo indica ningún problemas de enrutamiento actualmente ".
Además, hablamos con Newrelic, que también parecía desconocer el problema, a pesar de que, según ellos mismos, tiene una relación de trabajo muy estrecha con Heroku.
Newrelic 29/8 2012: "Parece que lo que está causando esto está sucediendo antes de que comience la visibilidad del agente Ruby. El tiempo de cola que el agente registra es desde el momento en que la solicitud ingresa a un banco de pruebas, por lo que la desaceleración se produce antes de eso".
El resultado final fue que terminamos pasando horas y horas optimizando el código que no era realmente el cuello de botella. Además, ejecutamos con una escala de dinamismo demasiado alta en un intento desesperado de aumentar nuestro rendimiento, pero lo único que obtuvimos de esto fueron los recibos más grandes de Heroku y Newrelic, NO COOL. Me alegra que hayamos cambiado.
PD. En ese momento, incluso había un error que causaba que newrelic pro se cargara en TODOS los dynos aunque nosotros, (de acuerdo con los consejos de Newrelics), habíamos deshabilitado el monitoreo en nuestros procesos de trabajo en segundo plano. Tomó mucho tiempo y muchos correos electrónicos antes de que ambas partes admitieran el error.
PPS. Si no está al tanto de la discusión actual en curso, aquí está el enlace http://rapgenius.com/James-somers-herokus-ugly-secret-lyrics
EDITAR 26/2 2013 Heroku acaba de announced en su boletín de noticias, que Newrelic ha lanzado una update que aparentemente debería arrojar algo de luz sobre la situación en Heroku.
EDITAR 8/4 2013 Heroku acaba de publicar una FAQ sobre el tema
Estamos en el proceso de mejorar el rendimiento de nuestra aplicación de rieles alojada en Heroku (rieles 3.2.8 y ruby 1.9.3). Durante esto, nos encontramos con un problema alarmante para el cual la fuente parece ser extremadamente difícil de rastrear. Permítanme explicar rápidamente cómo experimentamos el problema y cómo hemos tratado de aislarlo.
-
Desde alrededor de junio, hemos experimentado un comportamiento de retraso extraño en Time to First Byte en todo el sitio. Los problemas son obvios al usar el sitio (a veces la aplicación no responde durante 10-20 segundos), y también está presente en el análisis de cascada a través de webpagetest.org. Estamos basados en Dinamarca, pero obtenemos este resultado de cualquier host.
Para confirmar el problema, realizamos una prueba comparativa donde enviamos 300 solicitudes idénticas a una página simple y medimos el tiempo de respuesta. Si enviamos 300 solicitudes a la página principal, el tiempo medio de respuesta es inferior a 1 segundo, lo cual es bastante bueno. Lo que nos asusta es que 60 solicitudes requieren más del doble de ese tiempo y 40 de ellas demoran más de 4 segundos. Algunas solicitudes toman hasta 16 segundos.
Ninguna de estas solicitudes lentas aparece en New Relic, que usamos para la supervisión del rendimiento. No se muestra cola de solicitudes y los resultados son los mismos sin importar qué tan alto escalamos nuestros procesos web. Aún así, no pudimos rechazar que el problema fue causado por el código de la aplicación, por lo que probamos otro experimento en el que respondimos a la solicitud a través del middleware de rack.
Al colocar este middleware (TestMiddleware) al principio de la pila de rack, devolvimos una solicitud antes de que llegara a la aplicación, asegurándonos de que ninguno de los siguientes middleware o la aplicación Rails pudieran causar la demora.
Middleware setup:
$ heroku run rake middleware
use Rack::Cache
use ActionDispatch::Static
use TestMiddleware
use Rack::Rewrite
use Rack::Lock
use Rack::Runtime
use Rack::MethodOverride
use ActionDispatch::RequestId
use Rails::Rack::Logger
use ActionDispatch::ShowExceptions
use ActionDispatch::DebugExceptions
use ActionDispatch::RemoteIp
use Rack::Sendfile
use ActionDispatch::Callbacks
use ActiveRecord::ConnectionAdapters::ConnectionManagement
use ActiveRecord::QueryCache
use ActionDispatch::Cookies
use ActionDispatch::Session::DalliStore
use ActionDispatch::Flash
use ActionDispatch::ParamsParser
use ActionDispatch::Head
use Rack::ConditionalGet
use Rack::ETag
use ActionDispatch::BestStandardsSupport
use NewRelic::Rack::BrowserMonitoring
use Rack::RailsExceptional
use OmniAuth::Builder
run AU::Application.routes
Luego ejecutamos el mismo script para documentar el tiempo de respuesta y obtuvimos el mismo resultado. El tiempo de respuesta promedio fue de alrededor de 130 ms (obviamente más rápido porque no llega a la aplicación. Sin embargo, 60 solicitudes tomaron más de 400 ms y 25 solicitudes demoraron más de 1 segundo. De nuevo, con algunas solicitudes tan lentas como 16 segundos.
Una explicación podría estar relacionada con los saltos lentos en la red o la configuración de DNS, pero los resultados de traceroute se ven perfectamente bien.
Este resultado se confirmó al ejecutar el script de respuesta en otra aplicación de carriles 3.2 y ruby 1.9.3 alojada en Heroku, sin ningún comportamiento extraño.
La configuración de DNS sigue las recomendaciones de Heroku.
-
Estamos confundidos por decir lo menos. ¿Podría haber algo raro con la red de enrutamiento de Heroku? ¿Por qué diablos estamos viendo este extraño comportamiento? ¿Cómo nos deshacemos de eso? ¿Y por qué no podemos verlo en New Relic?
Traceroute no es una buena medida de problemas en la red, es una herramienta que puede encontrar fallas a lo largo de la red, pero no le mostrará la mejor vista.
Intenta simplemente colocar una página web estática y pégala con la dirección IP de tu probador de páginas web. Si aún es lento, culpe a la red.
Si por alguna razón es rápido, entonces tienes un problema diferente.