¿Qué pasa con las encuestas?

Question

He oído a algunos desarrolladores decir recientemente que simplemente están sondeando cosas (bases de datos, archivos, etc.) para determinar cuándo algo ha cambiado y luego ejecutar una tarea, como una importación.

Estoy realmente en contra de esta idea y creo que la utilización de la tecnología disponible como Remoting, WCF, etc. sería mucho mejor que la votación.

Sin embargo, me gustaría identificar las razones por las que otras personas prefieren un enfoque sobre el otro y, lo que es más importante, ¿cómo puedo convencer a otros de que las encuestas están equivocadas hoy en día?

Answer 1

El sondeo no es "incorrecto" como tal.

Mucho depende de cómo se implementa y con qué propósito. Si realmente te preocupa la notificación inmediata de un cambio, es muy eficiente. Su código se encuentra en un círculo cerrado, constantemente sondeando (preguntando) a un recurso si ha cambiado/actualizado. Esto significa que se le notificará tan pronto como sea posible que algo es diferente. Pero su código no está haciendo otra cosa y hay una sobrecarga en términos de muchas llamadas al objeto en cuestión.

Si le preocupa menos la notificación inmediata, puede aumentar el intervalo entre las encuestas, y esto también puede funcionar bien, pero elegir el intervalo correcto puede ser difícil. Demasiado tiempo y es posible que te pierdas los cambios críticos, demasiado cortos y vuelvas a los problemas del primer método.

Las alternativas, como interrupciones o mensajes, etc. pueden proporcionar un mejor compromiso en estas situaciones. Se le notifica un cambio tan pronto como sea prácticamente posible, pero esta demora no es algo que usted controle, sino que depende de que el componente sea oportuna para transmitir los cambios de estado.

¿Qué es "incorrecto" con las encuestas?

• Puede ser acaparamiento de recursos.
• Puede ser limitante (especialmente si tiene muchas cosas que desea saber sobre/encuesta).
• Puede ser exagerado.

Pero ...

• No es intrínsecamente malo.
• Puede ser muy efectivo.
• Es muy simple.

Answer 2

El sondeo es fácil de hacer, muy fácil, es tan fácil como cualquier código de procedimiento. No sondear significa que ingresas al mundo de la programación asincrónica, que no es tan fácil como un cerebro muerto, e incluso puede llegar a ser desafiante a veces.

Y como con todo en cualquier sistema, la ruta de menos resistencia normalmente se toma con más frecuencia, por lo que siempre habrá programadores que utilicen sondeos, incluso grandes programadores, porque a veces no hay necesidad de complicar las cosas con patrones asincrónicos.

Yo siempre prospero para evitar el sondeo, pero a veces realizo encuestas de todos modos, especialmente cuando las ganancias reales del manejo asincrónico no son tan buenas, como cuando se actúa contra algunos datos locales pequeños (por supuesto, obtienes un poco más rápido, pero los usuarios no notarán la diferencia en un caso como este). Así que hay espacio para ambas metodologías en mi humilde opinión.

Answer 3

Esto no está respondiendo a tu pregunta. Pero de forma realista, especialmente en este "día y edad" donde los ciclos de los procesadores son baratos y el ancho de banda es grande, las encuestas son en realidad una solución bastante buena para algunas tareas.

Los beneficios son:

• barato
• fiable
• comprobable
• flexible

Answer 4

Si usted es de sondeo para cambios en un archivo, entonces estoy de acuerdo que se debe utilizar las notificaciones del sistema de archivos que están disponibles para cuando esto sucede, que ahora están disponibles en la mayoría de los sistemas operativos.

En una base de datos, puede activar la actualización/inserción y luego llamar a su código externo para hacer algo. Sin embargo, puede ser que no tenga un requisito para acciones instantáneas. Por ejemplo, puede que solo necesite obtener datos de la Base de datos A en la Base de datos B en una red diferente en 15 minutos. Puede que no se pueda acceder a la Base de datos B desde la Base de datos A, por lo que terminará realizando el sondeo desde, o como un programa independiente que se ejecuta cerca de la Base de datos B.

Además, el sondeo es algo muy simple de programar. A menudo es una implementación de primer paso realizada cuando las restricciones de tiempo son cortas, y debido a que funciona lo suficientemente bien, se mantiene.

Answer 5

Existen dos motivos por los que las encuestas pueden considerarse malas por principio.

1. Es una pérdida de recursos. Es muy probable que verifique un cambio mientras no haya ocurrido ningún cambio. La duración de los ciclos de CPU/ancho de banda en esta acción no da como resultado un cambio y, por lo tanto, podría haberse gastado mejor en otra cosa.

2. El sondeo se realiza en un intervalo determinado. Esto significa que no sabrá que se ha producido un cambio hasta la próxima vez que pase el intervalo.

Sería mejor ser notificado de los cambios. De esta forma, no está buscando cambios que no se han producido y sabrá de un cambio tan pronto como reciba la notificación.

Answer 6

Lo que pasa con las encuestas es que funciona. Es confiable y simple de implementar.

Los costos de la agrupación pueden ser altos: si está escaneando una base de datos para ver los cambios cada minuto cuando solo hay dos cambios al día, está consumiendo una gran cantidad de recursos para obtener un resultado muy pequeño.

Sin embargo, el problema con cualquier tecnología de notificación es que son mucho más complejas de implementar y no solo no son confiables sino que (y esto es mucho PERO) no se puede decir fácilmente cuando no están funcionando.

Por lo tanto, si cancela el sondeo para alguna otra tecnología, asegúrese de que sea utilizable por los programadores promedio y sea extremadamente confiable.

Answer 7

Es simple: el sondeo es malo: ineficiente, pérdida de recursos, etc. Siempre hay alguna forma de conectividad que supervisa un evento de algún tipo, incluso si no se elige "votación".

¿Por qué hacer un esfuerzo adicional y realizar encuestas adicionales en su lugar?

Las devoluciones de llamada son la mejor opción, solo tiene que preocuparse por vincular la devolución de llamada con su proceso actual. Subyacente, hay encuestas para ver que la conexión todavía está en su lugar de todos modos.

Si sigue llamando/llamando a su novia y ella nunca responde, ¿por qué sigue llamando? Simplemente deje un mensaje y espere hasta que ella 'vuelva a llamar';)

Answer 8

Estoy de acuerdo en que evitar las encuestas es una buena política. Sin embargo, en referencia al Robert's post, diría que la simplicidad del sondeo puede hacer que sea un mejor enfoque en casos donde los problemas mencionados aquí no son un problema tan grande, ya que el enfoque asincrónico a menudo es considerablemente menos legible y más difícil de mantener, no mencionar los errores que pueden introducirse en su implementación.

Answer 9

Uso el sondeo de vez en cuando para ciertas situaciones (por ejemplo, en un juego, sondearía el estado del teclado en cada fotograma), pero nunca en un bucle que SÓLO hace el sondeo, en lugar de eso, lo haría como verificación (tiene recursos X cambió? En caso afirmativo, haga algo, de lo contrario procese algo diferente y vuelva a verificarlo más tarde). En términos generales, evito las encuestas a favor de las notificaciones asincrónicas.

Las razones son que no gasto recursos (tiempo de CPU, lo que sea) esperando que ocurra algo (especialmente si esos recursos podrían acelerar esa cosa en primer lugar). En los casos en los que utilizo encuestas, no me quedo esperando inactivo, utilizo los recursos en otra parte, por lo que no es un problema (para mí, al menos).

Answer 10

Como con todo, depende. Un gran sistema de alta transacción en el que trabajo actualmente usa una notificación con SQL (una DLL cargada dentro de SQL Server a la que un SP extendido llama desde disparadores en ciertas tablas. La DLL luego notifica a otras aplicaciones que hay trabajo por hacer).

Sin embargo, nos estamos alejando de esto porque prácticamente podemos garantizar que habrá trabajo para hacer continuamente. Por lo tanto, para reducir la complejidad y acelerar un poco las cosas, las aplicaciones procesarán su trabajo y volverán a sondear el DB de nuevo para un nuevo trabajo. Si no hay ninguno lo intentará de nuevo después de un pequeño intervalo.

Esto parece funcionar más rápido y es mucho más simple. Sin embargo, otra parte de la aplicación que tiene un volumen mucho más bajo no se beneficia de un aumento de velocidad con este método, a menos que el intervalo de sondeo sea muy pequeño, lo que conduce a problemas de rendimiento. Así que lo dejamos como está para esta parte. Por lo tanto, es bueno cuando es apropiado, pero las necesidades de todos son diferentes.

Answer 11

ejemplos de las cosas que utilizan votación en los tiempos que corren:

• Email clientes sondear los mensajes nuevos (incluso con IMAP).
• Los lectores de RSS sondean los cambios en los feeds.
• Encuesta de motores de búsqueda para los cambios en las páginas que indexan.
• StackOverflow encuesta de usuarios para nuevas preguntas, pulsando 'actualizar' ;-)
• Los clientes de Bittorrent sondean el rastreador (y entre ellos, creo, con DHT) para ver los cambios en el enjambre.
• Spinlocks en sistemas multi-core puede ser la sincronización más eficiente entre núcleos, en casos donde el retraso es demasiado corto para que haya tiempo para programar otro hilo en este núcleo, antes que el otro núcleo haga lo que estamos esperando .

A veces simplemente no hay forma de obtener notificaciones asíncronas: por ejemplo, para reemplazar RSS con un sistema de inserción, el servidor debería conocer a todo el que lea el feed y tenga una forma de contactarlos. Esta es una lista de correo, precisamente una de las cosas que RSS fue diseñado para evitar. De ahí el hecho de que la mayoría de mis ejemplos son aplicaciones de red, donde es más probable que esto sea un problema.

Otras veces, las encuestas son lo suficientemente baratas para funcionar incluso cuando hay una notificación asíncrona.

Para un archivo local, la notificación de cambios es probablemente la mejor opción en principio. Por ejemplo, es posible que (quizás) evite que el disco gire hacia abajo si lo golpea constantemente, aunque de nuevo el sistema operativo podría almacenar en caché. Y si está sondeando cada segundo en un archivo que solo cambia una vez por hora, puede estar ocupando innecesariamente el 0.001% (o lo que sea) de la potencia de procesamiento de su máquina. Esto suena pequeño, pero ¿qué sucede cuando hay 100.000 archivos que necesita sondear?

En la práctica, sin embargo, es probable que la sobrecarga sea despreciable, sea lo que sea que haga, haciendo que sea difícil entusiasmarse con el cambio de código que actualmente funciona. Lo mejor es tener cuidado con los problemas específicos que el sondeo causa en el sistema que desea cambiar; si encuentra alguno, eleve los mismos en lugar de intentar hacer un argumento general contra todos los sondeos. Si no encuentra ninguno, no puede reparar lo que no está roto ...

Answer 12

Creo que la gente debería darse cuenta de que en la mayoría de los casos, en algún nivel se están realizando encuestas, incluso en caso de evento o interrupción situaciones controladas, pero estás aislado del código real que realiza la votación. Realmente, esta es la situación más deseable ... aislarse de la implementación y simplemente tratar con el evento. Incluso si debe implementar la encuesta usted mismo, escriba el código para que esté aislado y los resultados se resuelvan independientemente de la implementación.

Answer 13

veo muchas respuestas aquí, pero creo que la respuesta más simple es la auto respuesta es:

Debido a que es (normalmente) mucho más fácil de codificar un bucle de sondeo a hacer la infraestructura para las devoluciones de llamada.

Luego, obtienes un código más simple que, si resulta ser un cuello de botella más tarde, puede ser fácilmente entendido y rediseñado/refactorizado en otra cosa.

Answer 14

El sondeo de clientes no se escala tan bien como las notificaciones del servidor. Imagine que miles de clientes le preguntan al servidor "¿Datos nuevos?" cada 5 segundos. Ahora imagine que el servidor mantiene una lista de clientes para notificar nuevos datos. La notificación del servidor se escala mejor.

Answer 15

Aquí es un buen resumen de los méritos relativos de empuje y atracción: https://stpeter.im/index.php/2007/12/14/push-and-pull-in-application-architectures/

Me gustaría poder resumir aún más en esta respuesta, pero algunas cosas son mejores íntegra izquierda.

Answer 16

Al pensar en el sondeo de SQL, en el día de VB6 solía ser capaz de crear conjuntos de registros utilizando la palabra clave WithEvents que era una encarnación temprana de la "escucha" asincrónica.

Personalmente siempre buscaba una forma de utilizar una implementación impulsada por eventos antes de la votación.En su defecto una aplicación manual de los cualquiera de los siguientes podría ayudar:

• sql clase corredor de servicio/dependencia
• algún tipo de tecnología de colas (RabbitMQ o similar)
• difusión UDP - técnica interesante que puede ser construido con múltiples oyentes de nodos. Sin embargo, no siempre es posible en algunas redes.

Algunos de estos pueden requerir un ligero rediseño de su proyecto, pero en un mundo empresarial podría ser el mejor camino a seguir en lugar de un servicio de votación.

Answer 17

De acuerdo con la mayoría de las respuestas que Async/Messaging suele ser mejor. Estoy absolutamente de acuerdo con la respuesta de Robert Gould. Pero me gustaría agregar un punto más.

Una adición es que la votación puede matar dos pájaros de un tiro. En un caso de uso particular, un proyecto en el que participé utilizó una cola de mensajes entre bases de datos, pero el sondeo de un servidor de aplicaciones a una de las bases de datos. Debido a que la red desde el servidor de la aplicación a la base de datos estaba ocasionalmente fuera de servicio, el sondeo se utilizó adicionalmente para notificar a la aplicación los problemas de la red.

Al final, utilice lo que hace que most sense para el caso de uso teniendo en cuenta la capacidad de escala.