Les Web Workers gérant les appels AJAX - une optimisation excessive ?

Question

Je travaille avec un code qui traite toutes les demandes AJAX en utilisant des Web Workers (lorsqu'ils sont disponibles). Ces travailleurs ne font presque rien de plus que XMLHttpRequest la manipulation des objets (pas de calculs supplémentaires). Toutes les requêtes créées par les workers sont asynchrones ( request.open("get",url,true) ).

Récemment, j'ai eu quelques problèmes concernant ce code et j'ai commencé à me demander si je devais passer du temps à le corriger ou simplement abandonner toute la solution.

Les recherches que j'ai effectuées jusqu'à présent suggèrent que ce code peut en fait nuire aux performances. Cependant, je n'ai pas pu trouver de source crédible à ce sujet. Mes deux seules conclusions sont :

• 2 ans Proposition de fonctionnalité de jQuery pour utiliser des travailleurs web pour les appels AJAX
• ce Question qui semble porter sur quelque chose d'un peu différent (utilisation de requêtes synchrones dans les travailleurs web par rapport aux appels AJAX).

Quelqu'un peut-il m'indiquer une source fiable traitant de cette question ? Ou bien, existe-t-il des points de référence qui pourraient dissiper mes doutes ?

[ EDIT Cette question devient un peu plus intéressante lorsque WebWorker est également responsable de l'analyse du résultat ( JSON.parse ). L'analyse syntaxique asynchrone améliore-t-elle les performances ?

Answer 1

J'ai créé un repère approprié pour cela sur jsperf . En fonction du navigateur, L'approche WebWorker est 85 à 95 % plus lente. qu'un appel ajax brut.

---

Notes :

• comme le temps de réponse du réseau peut être différent pour chaque demande, je ne teste que new XMLHttpRequest() et JSON.parse(jsonString); . Il n'y a pas de réel Des appels AJAX sont effectués.
• Les opérations d'installation et de démontage du WebWorker sont les suivantes pas être mesuré
• Notez que je teste une seule demande, les résultats de l'approche webworker peuvent être meilleurs pour plusieurs demandes simultanées.
• Calvin Metcalf m'a expliqué que comparer sync et async sur jsperf ne donne pas de résultats précis et il a créé une autre référence qui élimine le surcoût asynchrone. Les résultats montrent toujours que l'approche WebWorker est significativement plus lente.
• De la Discussion Reddit J'ai appris que les données passées entre la page principale et le WebWorker sont copiées et doivent être sérialisées dans le processus. Par conséquent, utiliser le WebWorker uniquement pour l'analyse syntaxique n'a pas beaucoup de sens, les données devront de toute façon être sérialisées et désérialisées avant de pouvoir les utiliser sur la page principale.

Answer 2

La première chose à retenir est que les web workers accélèrent rarement les choses dans le sens où ils prennent moins de temps, ils accélèrent les choses dans le sens où ils déchargent le calcul vers un thread d'arrière-plan afin que le traitement lié à l'interaction de l'utilisateur ne soit pas bloqué. Par exemple, si l'on prend en compte le transfert des données, un calcul important peut prendre 8 secondes au lieu de 4. Mais s'il était effectué sur le thread principal, la page entière serait gelée pendant 4 secondes, ce qui est inacceptable.

En gardant cela à l'esprit, déplacer les appels ajax hors du thread principal ne vous apportera rien car les appels ajax sont non bloquants. Mais si vous devez analyser le JSON ou, mieux encore, extraire un petit sous-ensemble d'une requête volumineuse, un web worker peut vous aider.

Une mise en garde que j'ai entendue, mais qui n'a pas été confirmée, est que les travailleurs utilisent un cache différent de celui de la page principale, de sorte que si les mêmes ressources sont chargées dans le fil principal et dans le travailleur, cela pourrait entraîner une importante duplication des efforts.

Answer 3

L'entrée-sortie asynchrone est un concept important de Javascript.

Tout d'abord, votre demande est déjà asynchrone, l'entrée-sortie est non bloquante et pendant votre demande, vous pouvez exécuter tout autre code Javascript. Exécuter le callback dans un worker est beaucoup plus intéressant que la requête.

Deuxièmement, les moteurs Javascript exécutent tout le code dans le même fil Si vous créez de nouveaux threads, vous devez gérer la communication des données avec le système de gestion des données de l'entreprise. api pour les messages des travailleurs (voir Sémaphore ).

En conclusion, la nature asynchrone et monofilaire de JavaScript est puissante, utilisez-la autant que possible et ne créez des workers que si vous en avez vraiment besoin, par exemple dans un long processus Javascript.

Answer 4

Vous optimisez votre code au mauvais endroit.

Les requêtes AJAX s'exécutent déjà dans un thread séparé et retournent dans la boucle d'événement principale une fois qu'elles sont remplies (et appellent la fonction de rappel définie).

Les travailleurs Web sont une interface avec les threads, destinés aux opérations coûteuses en termes de calcul. Tout comme dans les applications de bureau classiques, lorsque vous ne voulez pas bloquer l'interface avec des calculs qui prennent beaucoup de temps.

Answer 5

D'après mon expérience, les Web Workers ne devrait pas être utilisé pour les appels AJAX. Tout d'abord, ils sont asynchrones, ce qui signifie que le code continuera à s'exécuter pendant que vous attendez le retour de l'information.

L'utilisation d'un travailleur pour gérer la réponse est tout à fait possible avec le Web Worker. Quelques exemples :

• Analyse de la réponse pour construire un grand modèle
• Calculer de grandes quantités de données à partir de la réponse
• Utilisation d'un Web Worker partagé avec un moteur de modèles en conjonction avec la réponse AJAX pour construire le HTML qui sera ensuite renvoyé pour être ajouté au DOM.

Edit : une autre bonne lecture serait : Opinion sur les requêtes synchrones dans les travailleurs web