¿Qué hay de malo en las encuestas?

https://stackoverflow.com/questions/320284

11-07-2019
|

Pregunta

Recientemente escuché a algunos desarrolladores decir que simplemente están encuestando 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 al utilizar la tecnología disponible, como Remoting , WCF , etc. sería mucho mejor que el sondeo.

Sin embargo, me gustaría identificar las razones por las cuales 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 mal hoy en día?

Solución

El sondeo no es '' incorrecto '' como tal.

Mucho depende de cómo se implemente y para qué propósito. Si realmente le importa la notificación inmediata de un cambio, es muy eficiente. Su código se encuentra en un circuito cerrado, constantemente sondeando (preguntando) 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 nada más 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 puede perder cambios críticos, demasiado cortos y volver 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 este retraso no es algo que usted controle, depende de que el componente sea oportuno para transmitir los cambios de estado.

¿Qué está mal? con sondeo?

Puede ser acaparar recursos.
Puede ser limitante (especialmente si tiene muchas cosas que desea saber sobre / sondeo).
Puede ser excesivo.

Pero ...

No es inherentemente incorrecto.
Puede ser muy efectivo.
Es muy simple.

Otros consejos

Hay dos razones por las cuales las encuestas pueden considerarse malas por principio.

Es un desperdicio de recursos. Es muy probable que verifique un cambio mientras no se haya producido ningún cambio. Los ciclos de CPU / gasto de ancho de banda en esta acción no dan como resultado un cambio y, por lo tanto, podrían haberse gastado mejor en otra cosa.
El sondeo se realiza en un cierto intervalo. Esto significa que no sabrá que ha ocurrido un cambio hasta la próxima vez que haya pasado el intervalo.

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

Ejemplos de cosas que usan encuestas en estos tiempos:

Los clientes de correo electrónico sondean por nuevos mensajes (incluso con IMAP).
Los lectores RSS sondean en busca de cambios en los feeds.
Los motores de búsqueda sondean en busca de cambios en las páginas que indexan.
Los usuarios de StackOverflow sondean para nuevas preguntas, presionando 'actualizar' ;-)
Los clientes de Bittorrent sondean el rastreador (y entre ellos, creo, con DHT) en busca de cambios en el enjambre.
Spinlocks en sistemas de múltiples núcleos 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 de que el otro núcleo haga lo que sea que estemos esperando .

A veces simplemente no hay forma de recibir notificaciones asincrónicas: por ejemplo, para reemplazar RSS con un sistema push, el servidor tendría que conocer a todos los que leen el feed y tener una forma de contactarlos. Esta es una lista de correo: precisamente una de las cosas que RSS fue diseñada 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, el sondeo es lo suficientemente barato como para funcionar incluso cuando hay una notificación asíncrona.

Para un archivo local, la notificación de cambios probablemente sea la mejor opción en principio. Por ejemplo, podría (podría) evitar que el disco gire hacia abajo si lo está empujando para siempre, aunque de nuevo el sistema operativo podría almacenarse en caché. Y si está sondeando cada segundo en un archivo que solo cambia una vez por hora, es posible que esté 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?

Sin embargo, en la práctica, es probable que los gastos generales sean insignificantes, independientemente de lo que haga, lo que dificulta entusiasmarse por cambiar el código que actualmente funciona. Lo mejor es tener cuidado con los problemas específicos que las encuestas causan en el sistema que desea cambiar; si encuentra alguno, plantee esos problemas en lugar de tratar de hacer un argumento general en contra de todas las encuestas. Si no encuentra ninguno, entonces no puede arreglar lo que no está roto ...

El sondeo es fácil de hacer, muy fácil, es tan fácil como cualquier código de procedimiento. No sondear significa que entras en el mundo de la programación asincrónica, que no es tan fácil y puede llegar a ser un desafío a veces.

Y como con todo en cualquier sistema, el camino de menor resistencia normalmente se toma más comúnmente, por lo que siempre habrá programadores que utilicen encuestas, incluso grandes programadores, porque a veces no es necesario complicar las cosas con patrones asincrónicos.

Por mi parte, siempre prospero para evitar el sondeo, pero a veces lo hago 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, se vuelve un poco más rápido , pero los usuarios no notarán la diferencia en un caso como este). Por lo tanto, hay espacio para ambas metodologías en mi humilde opinión.

Las encuestas de clientes no se escalan tan bien como las notificaciones del servidor. ¿Imagina miles de clientes preguntando al servidor " algún dato nuevo? & Quot; cada 5 segundos Ahora imagine que el servidor mantiene una lista de clientes para notificar los nuevos datos. La notificación del servidor se escala mejor.

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 sondeos, incluso en situaciones de eventos o interrupciones, pero está aislado del código real que realiza el sondeo. Realmente, esta es la situación más deseable ... aislarse de la implementación y lidiar con el evento. Incluso si debe implementar el sondeo usted mismo, escriba el código para que esté aislado y los resultados se traten independientemente de la implementación.

Es simple: el sondeo es malo: ineficiente, desperdicio de recursos, etc. Siempre hay alguna forma de conectividad que supervisa un evento de algún tipo, incluso si no se elige 'sondeo'.

Entonces, ¿por qué hacer un esfuerzo adicional y poner encuestas adicionales en su lugar?

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

Si sigues llamando / llamando a tu novia y ella nunca contesta, ¿por qué seguir llamando? Simplemente deje un mensaje y espere hasta que 'vuelva a llamar';)

Utilizo el sondeo ocasionalmente para ciertas situaciones (por ejemplo, en un juego, sondearía el estado del teclado en cada fotograma), pero nunca en un bucle que SOLO realiza el sondeo, sino que lo haría como un control (tiene el recurso X cambiado? En caso afirmativo, haga algo, de lo contrario, procese otra cosa y vuelva a verificar más tarde). Sin embargo, 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 algo suceda (especialmente si esos recursos podrían acelerar que eso ocurra en primer lugar). En los casos en que utilizo encuestas, no me quedo inactivo esperando, utilizo los recursos en otros lugares, por lo que no es un problema (para mí, al menos).

Si está buscando cambios en un archivo, acepto que debe usar las notificaciones del sistema de archivos que están disponibles para cuando esto suceda, que están disponibles en la mayoría de los sistemas operativos ahora.

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, es posible que solo necesite obtener datos de la Base de datos A a la Base de datos B en una red diferente en 15 minutos. Es posible que no se pueda acceder a la base de datos B desde la base de datos A, por lo que termina haciendo el sondeo desde, o como un programa independiente que se ejecuta cerca de la base de datos B.

Además, el sondeo es muy sencillo de programar. A menudo es una implementación de primer paso cuando las limitaciones de tiempo son cortas, y debido a que funciona lo suficientemente bien, permanece.

¡Lo que pasa con las encuestas es que funciona! Es confiable y fácil de implementar.

Los costos de la agrupación pueden ser altos: si está escaneando una base de datos en busca de cambios cada minuto cuando solo hay dos cambios al día, está consumiendo muchos 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 pueden ser poco confiables, sino que (y esto es un GRAN PERO) no se puede determinar fácilmente cuando no están funcionando.

Entonces, si abandona el sondeo de alguna otra tecnología, asegúrese de que sea utilizable por programadores promedio y que sea ultra confiable.

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

Porque (generalmente) es mucho más simple codificar un bucle de sondeo que crear la infraestructura para devoluciones de llamada.

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

Esto no responde tu pregunta. Pero de manera realista, especialmente en este "día y edad" donde los ciclos del procesador son baratos y el ancho de banda es grande, el sondeo es en realidad una solución bastante buena para algunas tareas.

Los beneficios son:

Barato
Fiable
comprobable
Flexible

Estoy de acuerdo en que evitar las encuestas es una buena política. Sin embargo, en referencia a la publicación de Robert , diría que la simplicidad del sondeo puede hacerlo un mejor enfoque en los casos en que 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, sin mencionar los errores que pueden aparecer en su implementación.

Como con todo, depende. Un gran sistema de alta transacción en el que trabajo actualmente utiliza una notificación con SQL (un archivo DLL cargado dentro de SQL Server que es llamado por un SP extendido desde los disparadores en ciertas tablas. El archivo DLL notifica a otras aplicaciones que hay trabajo por hacer).

Sin embargo, nos estamos alejando de esto porque prácticamente podemos garantizar que habrá trabajo que hacer continuamente. Por lo tanto, para reducir la complejidad y acelerar un poco las cosas, las aplicaciones procesarán su trabajo e inmediatamente volverán a sondear la base de datos en busca de nuevo trabajo. Si no hay ninguno, lo intentará nuevamente 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 menor 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 genera 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.

Aquí hay un buen resumen de los méritos relativos de empujar y tirar: https://stpeter.im /index.php/2007/12/14/push-and-pull-in-application-architectures/

Desearía poder resumirlo más en esta respuesta, pero es mejor dejar algunas cosas sin resumir.

Cuando pensaba en el sondeo SQL, en el día de VB6 solía ser capaz de crear conjuntos de registros utilizando la palabra clave WithEvents, que fue una encarnación temprana de asíncrono "escuchar".

Personalmente, siempre buscaría una forma de utilizar una implementación dirigida por eventos antes de la encuesta. Si no se puede ayudar una implementación manual de cualquiera de los siguientes:

agente de servicio sql / clase de dependencia
Algún tipo de tecnología de cola (RabbitMQ o similar)
difusión UDP: técnica interesante que puede ser construido con múltiples nodos de escucha. 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 la mejor ruta a seguir en lugar de un servicio de votación.

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

Una adición es que las encuestas pueden matar dos pájaros de un tiro. En un caso de uso particular, un proyecto en el que estuve involucrado usó una cola de mensajes entre bases de datos pero sondeo desde un servidor de aplicaciones a una de las bases de datos. Debido a que la red del servidor de aplicaciones a la base de datos estaba ocasionalmente inactiva, el sondeo también se usó para notificar a la aplicación sobre problemas de red.

Al final, use lo que tiene más sentido para el caso de uso con la capacidad de escala en mente.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow