Mejores formas que los métodos de votación tradicionales.

Actualmente estoy en un entorno AngularJS / Javascript.

Actualmente, la aplicación utiliza el método de sondeo (es decir, para recuperar nuevos datos del servidor en una cantidad fija de segundos).

Esto es bastante exigente y no recupera el último resultado de inmediato. Suponiendo que el servidor usa ASMX para las funciones de servicio web y, si es posible, sin una revisión importante, ¿cómo puedo mejorar la eficiencia de la aplicación?

Editar 1:

Por impuestos, quiero decir que el servidor tendría que extraer diferentes tablas SQL y datos y cosas asociadas, lo que significa un procesamiento de datos complejo que, si hay muchos usuarios concurrentes, me temo que podría haber posibles problemas con el rendimiento del servidor en el futuro.

Los datos más recientes no se recuperarán ya que actualmente la aplicación está utilizando el tipo de llamadas https solicitud-respuesta.

Puedo mejorar más en el lado de la aplicación móvil, pero no puedo modificar mucho en el lado del servidor, aparte de los archivos de servicio web del servidor.

Si por "tradicional" te refieres a cada cliente que golpea el servidor con la mayor frecuencia posible, entonces puedo ayudar a nivel arquitectónico.

El diseño apropiado depende de dónde cae su servidor en esta cuadrícula:

Control \ Resources : Sufficient | Insufficient
Customizable        :     SC     |     IC
Untouchable         :     SU     |     IU

• SC: Haga que el servidor siga el patrón de observador . Permita que los clientes se registren como observadores.

• IC: solo permite que un sistema proxy se registre con el servidor. Los clientes se registran con proxy.

• SU: solo permita que un sistema proxy sondee el servidor. Los clientes se registran con proxy.

• IU: solo permite que un sistema proxy sondee el servidor. Los clientes se registran con proxy.

Un proxy que sigue el patrón de observador puede resolver problemas de personalización y recursos. Esto funciona tan bien en Internet como lo es entre objetos. Cuando te registras, estás pidiendo que te llamen cuando sucede algo. Escuche en un puerto y estará listo para ser llamado. ajax, REST, UDP, lo que sea.

El problema con el sondeo es que el observador controla cuándo ocurre la llamada pero no sabe cuándo cambia el estado, por lo que realiza muchas llamadas innecesarias. Esto consume recursos, especialmente cuando hay muchos observadores. La clave para lidiar con las encuestas es: tan pronto como sea posible, obtenga la dirección de las llamadas que van desde el punto de cambio de estado al observador. Entonces las llamadas suceden cuando se necesitan. No cuando no lo son.

Si tiene llamadas de sondeo de esta manera:

• Servidor <=== Muchos observadores

Cualquiera de estos sería una mejor manera de detectar cambios:

• SC: Servidor ===> Muchos observadores

• IC: Servidor ===> Un proxy ===> Muchos observadores

• SU: Servidor <=== Un proxy ===> Muchos observadores

• IU: Servidor <=== Un proxy ===> Muchos observadores

Puede usar Server-Sent-Events como una alternativa al sondeo.

En lugar de pedirle a su servidor nuevos datos cada n segundos, abra una conexión dedicada y haga que envíe sus nuevos datos cuando estén disponibles.

La conexión permanecerá abierta hasta que el cliente o el servidor la cierren explícitamente (o por su terminación repentina).

Puede configurar su servidor para transmitir datos a su cliente a intervalos fijos, o en momentos específicos en su servidor (digamos cuando un objeto cambia de estado o cuando un programador dispara un trabajo o cuándo).

Puede definir diferentes tipos de eventos y hacer que diferentes rutinas manejen diferentes tipos de eventos.

En el lado del servidor, puede mantener una cola de usuarios actualmente suscritos a su tipo de aplicación / evento, cuando se crea un evento, su servidor lo transmitirá a todos los usuarios en la cola. Marcos como Jersey2 ya implementan este enfoque utilizando un objeto Broadcaster .

En el lado del cliente, tendrá que escribir un servicio que escuche los eventos enviados por el servidor en una URL específica .

Cuando ingrese un estado / ruta, deberá suscribirse a un tipo de servidor y cancelar la suscripción $destroypara evitar una fuga.

Son websockets: son una extensión de HTTP, funcionan en el mismo puerto.

Permite la comunicación bidireccional entre el cliente y el servidor y, por supuesto, hay una integración angularjs disponible para eso.

De lo contrario, en el lado de la oficina administrativa, si observa Spring en Java, hay otras formas de hacerlo:

• Sondeo largo
• PISAR MUY FUERTE
• ...

Este enlace Covevr Websocket y otros métodos adaptados a lo que necesita.

Tenga en cuenta que si no tiene Spring / Java, debería leerlo y buscar una solución equivalente en su pila de tecnologías.

Necesita definir mejor cosas como "bastante exigente" y explorar por qué no recupera el último resultado de inmediato. Estas son preguntas que probablemente sucedan independientemente de si está encuestando a su cliente o no.

Dicho esto, con un front-end basado en navegador, básicamente tiene dos opciones si desea permanecer en JavaScript nativo: sondeo (como lo está haciendo, o posiblemente sondeo largo) o sockets web. No he visto sockets web hechos con ASMX antes (sin decir que no se puede hacer, solo que no tengo experiencia allí, así que no sé lo difícil que sería volver a implementarlo). Además, si tiene problemas de rendimiento o precisión, como dije, bien podrían estar ahí incluso con el uso de sockets web.