Heroku: dinamómetro web vs dinamómetro trabajador? ¿Cuántos / qué proporción necesito?

Tenía curiosidad por saber cuál es la diferencia entre web y dynos de trabajador en Heroku. Dan una explicación de una oración en su página de precios, pero esto me dejó confundido. ¿Cómo sé cuántos elegir de cada uno? ¿Hay una proporción a la que debería aspirar? Soy bastante nuevo en esto, así que ¿alguien puede dar una explicación en profundidad, o tal vez alguna forma de calcular cuántos y qué tipo de dinamómetros necesitaría?

Además, estoy confundido acerca de lo que quieren decir con la cantidad de horas para cada banco de pruebas.

http://www.heroku.com/pricing

También me encontré con este artículo. Como una de sus soluciones sugeridas, dijeron aumentar la cantidad de dinamómetros. ¿A qué tipo de banco de pruebas se refieren aquí?

http://devcenter.heroku.com/articles/backlog-too-deep

Su mejor indicación si necesita más dynos (también conocidos como procesos en Cedar) son sus registros de heroku. Asegúrese de actualizar al registro ampliado (es gratis) para que pueda seguir su registro.

Está buscando las entradas de heroku.router y el valor que más le interesa es el valor de la cola; si es constantemente superior a 0, es una buena señal de que necesita agregar más dinamizadores. Básicamente, esto significa que ingresan más solicitudes de las que su proceso puede manejar, por lo que se ponen en cola. Si están en cola durante demasiado tiempo sin devolver ningún dato, se agotarán.

Me temo que no hay una proporción ideal, podría tener una aplicación que haga 100 solicitudes por segundo y necesite muchos procesos web, pero que simplemente no utilice trabajadores. Solo necesita procesos de trabajo si está procesando en segundo plano, como enviar correos electrónicos, etc.

ps Backlog demasiado profundo sería un proceso web de Dyno que lo causaría.

ACTUALIZACIÓN: El 26 de marzo de 2013, Heroku eliminó los campos de espera y cola del cierre de sesión.

Los campos de cola y espera se han eliminado de los mensajes de registro del enrutador. Además, el enrutador Heroku ya no configura los encabezados HTTP X-Heroku-Dynos-In-Use, X-Heroku-Queue-Depth y X-Heroku-Queue-Wait-Time para las solicitudes entrantes.

Dynos son básicamente procesos que se ejecutan en su instancia. Con la nueva pila Cedar, se pueden configurar para ejecutar cualquier comando de shell arbitrario. Para las aplicaciones web, generalmente tiene un proceso llamado "web" que es responsable de responder a las solicitudes HTTP de los usuarios. Todos los demás procesos son lo que antes se llamaba "trabajadores". Estos se ejecutan continuamente en segundo plano para cosas como cron, colas de procesamiento y cualquier cálculo pesado que no desee que atasque sus procesos web. También puede escalar cada tipo de proceso, de modo que se inicien múltiples procesos de cada tipo para una simultaneidad adicional. La cantidad de cada uno que use realmente depende de las necesidades de su aplicación y la carga que recibe. Puede usar herramientas como el complemento New Relic para monitorear estas cosas.

Varias personas han mencionado que no existe una proporción conocida y que la proporción de trabajadores web a trabajadores 'en segundo plano' que querrá dependerá de cómo diseñó su aplicación, eso es correcto. Sin embargo, pensé que podría ser útil agregar que, como regla general, desea que sus trabajadores web, y por lo tanto, las acciones del controlador que realizan, sean muy rápidas y muy ligeras, para reducir la latencia en los tiempos de respuesta de las acciones del navegador. Si hay alguna acción del navegador que requeriría más de, digamos, alrededor de medio segundo de tiempo real para servir, entonces probablemente querrá diseñar algún tipo de sistema que empuje la mayor parte de esa acción a una cola.

Luego, diseñaría un dinamómetro de trabajador fuera de línea que atenderá esta cola. Pueden tardar mucho más porque no hay respuestas HTTP pendientes en su salida. Quizás la página que renderizó desde la solicitud inicial del navegador que impulsó la acción servirá algo de Javascript que inicie un hilo que verifique si la solicitud ha finalizado cada 5 segundos, o algo por el estilo.

Todavía no puedo darte una proporción con la que trabajar por la misma razón que otros han dado, pero espero que esto te ayude a decidir cómo diseñar tu aplicación. (También debo mencionar que este es solo un diseño entre muchos válidos).

https://stackoverflow.com/a/19965981/1233555 - Heroku ha pasado al enrutamiento aleatorio, por lo que algunos dynos pueden tener colas apiladas (mientras atienden una solicitud larga) mientras que otros dynos son gratuitos. Evite esto asegurándose de que todas las solicitudes se manejen muy rápidamente en sus dinámicos web. Esto reducirá la cantidad de dinámicos web que necesita, al tiempo que requerirá más dinámicos de trabajo.

También debe preocuparse por la simultaneidad de soporte de su aplicación web, lo que solo hacen algunas configuraciones de Rails: pruebe Unicorn o código escrito cuidadosamente (para E / S que no bloquea EventMachine) con Thin.

Probablemente tenga que probar, en lugar de calcular, para ver cuántos dinamómetros de cada tipo necesita. Asegúrese de que su New Relic informe la cola del dinamómetro; consulte el enlace anterior.

La respuesta corta es que necesita tantas como necesite para mantener sus colas reducidas.

Como describe John, si comienza a ver una cola en sus registros, entonces necesita más dinamizadores. Si comienza a ver que sus colas en segundo plano se vuelven demasiado largas (la forma de obtener esta información depende de lo que haya implementado), entonces necesita más trabajadores.

No existe una proporción, ya que depende en gran medida del diseño y el uso de su aplicación.