uso - pasar variable de javascript a php por ajax

Trabajadores web que manejan llamadas AJAX: ¿exceso de optimización? (5)

Estoy trabajando con un código que maneja todas las solicitudes AJAX utilizando Web Workers (cuando esté disponible). Estos trabajadores no hacen casi nada más que el manejo de objetos XMLHttpRequest (sin cálculos adicionales). Todas las solicitudes creadas por los trabajadores son asincrónicas ( request.open("get",url,true) ).

Recientemente, tengo un par de problemas con respecto a este código y comencé a preguntarme si debería perder tiempo solucionándolo o simplemente volcar toda la solución.

Mi investigación hasta ahora sugiere que este código puede estar perjudicando el rendimiento. Sin embargo, no pude encontrar ninguna fuente creíble que apoye esto. Mis únicos dos hallazgos son:

Sugerencia de jQuery de 2 años para utilizar web workers para llamadas AJAX
this pregunta TAN que parece preguntar acerca de algo un poco diferente (utilizando solicitudes sincrónicas en trabajadores web frente a llamadas AJAX)

¿Puede alguien señalarme una fuente confiable para discutir este tema? O bien, ¿hay puntos de referencia que puedan disipar mis dudas?

[ EDITAR ] Esta pregunta se vuelve un poco más interesante cuando WebWorker también es responsable de analizar el resultado ( JSON.parse ). ¿El análisis asincrónico mejora el rendimiento?

Asynchronous IO es un concepto importante de Javascript.

En primer lugar, su solicitud ya es asincrónica, el IO no tiene bloqueo y, durante su solicitud, puede ejecutar cualquier otro código de Javascript. Ejecutar la devolución de llamada en un trabajador es mucho más interesante que la solicitud.

En segundo lugar, los motores de Javascript ejecutan todo el código en el mismo hilo , si crea nuevos hilos, necesita manejar la comunicación de datos con la api del mensaje de trabajador (ver Semaphore ).

En conclusión, la naturaleza asíncrona y de subproceso único de JavaScript es poderosa, utilícela tanto como sea posible y cree trabajadores solo si realmente la necesita, por ejemplo, en un proceso largo de Javascript.

Está optimizando su código en el lugar equivocado.

Las solicitudes AJAX ya se ejecutan en un hilo separado y vuelven al bucle de evento principal una vez que se cumplen (y llaman a la función de devolución de llamada definida).

Los trabajadores de la web son una interfaz para los hilos, destinados a operaciones computacionalmente costosas. Al igual que en las aplicaciones de escritorio clásicas cuando no desea bloquear la interfaz con cálculos que tardan mucho tiempo.

He creado un punto de referencia adecuado para eso en jsperf . Dependiendo del navegador, el enfoque WebWorker es 85-95% más lento que una llamada ajax sin formato.

Notas:

dado que el tiempo de respuesta de la red puede ser diferente para cada solicitud, solo estoy probando new XMLHttpRequest() y JSON.parse(jsonString); . No se están realizando llamadas AJAX reales .
Las operaciones de instalación y desmontaje de WebWorker no se están midiendo
Tenga en cuenta que estoy probando una única solicitud, los resultados para el enfoque de webworker pueden ser mejores para múltiples solicitudes simultáneas
Calvin Metcalf me explicó que la comparación de sincronización y asincronización en jsperf no dará resultados precisos y creó otro punto de referencia que elimina la sobrecarga asincrónica. Los resultados aún muestran que el enfoque de WebWorker es significativamente más lento.
De la discusión de Reddit , aprendí que los datos que se pasan entre la página principal y WebWorker se copian y deben ser serializados en el proceso. Por lo tanto, usar WebWorker para analizar solo no tiene mucho sentido, los datos tendrán que ser serializados y deserializados de todos modos antes de poder usarlos en la página principal.

Lo primero que hay que recordar es que los trabajadores web rara vez aceleran las cosas en el sentido de tomar menos tiempo, hacen las cosas más rápido en el sentido de que descargan el cómputo a un hilo de fondo para que no se bloquee el procesamiento relacionado con la interacción del usuario. Por ejemplo, cuando se tiene en cuenta la transferencia de datos, hacer un cálculo enorme puede llevar 8 segundos en lugar de 4. Pero si se hizo en el hilo principal, la página entera se congelaría durante 4 segundos, lo que probablemente sea inaceptable.

Con eso en mente, mover solo las llamadas ajax del hilo principal no te hará ganar nada ya que las llamadas ajax no son de bloqueo. Pero si tiene que analizar JSON o incluso mejor, extraer un subconjunto pequeño de una solicitud grande, entonces un trabajador web puede ayudarlo.

Una advertencia que he escuchado pero no confirmado es que los trabajadores usan una memoria caché diferente a la página principal, de modo que si los mismos recursos se están cargando en el hilo principal y el trabajador podría causar una gran duplicación de esfuerzos.

Según mi experiencia, Web Workers no debe usarse para llamadas AJAX. En primer lugar, son asincrónicos, lo que significa que el código seguirá ejecutándose mientras espera que la información regrese.

Ahora, usar a un trabajador para manejar la respuesta es definitivamente algo para lo que podría usar Web Worker. Algunos ejemplos:

Analizando la respuesta para construir un modelo grande
Computando grandes cantidades de datos de la respuesta
Usar un Trabajador web compartido con un motor de plantilla junto con la respuesta AJAX para compilar el HTML que luego se devolverá para agregar al DOM.

Editar: otra buena lectura sería: this