Pourquoi Flex utilise-t-il un seul modèle fileté?

Question

Au cours des dernières semaines, j'ai construit un prototype d'application utilisant un frontal Flex connecté à un backend J2EE en utilisant blazeDS. Le prototype est une expérience pour apprendre le flex et voir quelle est sa pertinence pour une application de trading complexe nécessitant un grand nombre de mises à jour dynamiques (c'est-à-dire 20 secondes) via un modèle de sous-pub.

Lors de certains tests de performances légers, il est devenu évident que j'ai besoin d'utiliser plusieurs threads pour garantir que l'interface utilisateur reste stable lors de la réception d'un grand nombre de mises à jour du serveur. Tout allait bien jusqu'à ce que je découvre que Flex a un seul modèle de programmation fileté! D'un rapide Google, il semble qu'il y ait de nombreux hacks pour implémenter un comportement similaire à celui des threads. Je suis sûr que beaucoup de gens ont dû faire face à un problème similaire. Peut-on me le faire savoir:

• Y a-t-il des libs bons de filetage qui sont bien entretenus, etc.
• ce que d'autres technologies RIA telles que silverlight ont les mêmes problèmes.
• Pourquoi abobe a-t-il implémenté un seul modèle de thread?
• Y at-il d'autres astuces que je peux utiliser pour m'assurer que mon interface utilisateur est stable.

Answer 1

J'ai vu des types d'applications Flex très intensifs pour les traders qui fonctionnent bien dans le modèle à un seul thread de Flex. La raison en est que les applications Flex en interne utilisent les réseaux d'E/S asynchrones. L'interface utilisateur ne bloque donc pas lorsque vous effectuez les demandes. Vous pourriez rencontrer des limitations avec BlazeDS et devrait peut-être envisager quelque chose qui utilise RTMP (comme LCDS). RTMP est un protocole plus efficace pour diffuser de grandes quantités de données au client. Il existe également des moyens d'optimiser le traitement des événements côté client et le code de rendu afin de ne pas ralentir l'interface utilisateur. Christophe Coenraets a quelques bonnes démos à faire ce genre de chose: http://coenraets.org/blog/?s=trader+desktop

Ce que vous essayez de faire est certainement possible avec Flex et il y a des gens qui l'ont fait avec succès.

Cependant, il y a une demande de fonctionnalité ouverte à cet effet sur bugs.adobe.com: https://bugs.adobe.com/jira/browse/ASL-23

Answer 2

Si vous rencontrez des problèmes avec la stabilité de l'interface utilisateur, il pourrait très bien que vous ne faites pas approprié utilisation du modèle UIComponent dans Flex. Il fonctionne sur la base d'un modèle d'invalidation/validation qui permet de différer les mises à jour jusqu'à ce que le thread de l'interface utilisateur soit prêt à repeindre l'écran. Il y a une grande présentation ici:

http://tv.adobe.com/#vi+f15384v1002

Même si votre application Flex avait encore des difficultés à gérer les mises à jour 20-30 UI par seconde après ces optimisations, ce que l'homme peut réellement donner un sens à des données changer à ce taux? J'imagine que rafraîchir l'interface utilisateur une fois par seconde serait suffisant tant que l'ensemble de données complet était disponible pour les calculs et les analyses.

Answer 3

Vous ne savez pas si vous l'avez déjà vu, mais vous pouvez utiliser PixelBender pour obtenir une application Flash multi-thread. Voir Using Pixel Bender to do heavy lifting calculations, makes Flash Player multi-thread.

Bonne chance!

Juan

Answer 4

que je fais quelque chose de très semblable à cela et la limitation n'est pas le seul fil, il est vraiment avec toutes les données qui sont envoyées en arrière et essayer de mettre à jour ce en temps réel. Le fait est, vous n'avez pas besoin de temps réel, ou au moins vous pouvez plier ce que "temps réel" signifie vraiment. Sur le côté serveur, au lieu de pousser les données immédiatement après un appui précédent, attendez une seconde et vérifiez si d'autres mises à jour arrivent. Si c'est le cas, vous pouvez appuyer sur ces données mises à jour. Il n'y a aucune raison de retourner immédiatement des données "en temps réel", si une milliseconde plus tard, vous allez retourner une autre mise à jour. Je déteste dire que le sondage est le moyen d'aller ici, parce que ce n'est pas le cas, mais le pseudo-sondage ou la réponse différée est la voie à suivre. Chose comme un train tirant dans une station, et laissant juste une personne. Il est beaucoup plus efficace de s'arrêter et d'attendre 50.

Answer 5

Pour répondre à votre question à propos de Silverlight, il permet en fait plusieurs têtes.

Answer 6

Pourquoi abobe a-t-il implémenté un seul modèle de thread ?

Adobe ne l'a pas fait. Macromedia a fait. Le modèle mono-thread est au cœur même de la machine virtuelle. Ils devraient écrire la VM ActionScript depuis le début pour introduire un modèle fileté.

Answer 7

Si votre interface utilisateur se bloque lors de l'envoi ou de la réception de messages pub/sub, cela est probablement dû au message (de)/sérialisation des données. L'astuce consiste à limiter les charges utiles sans aucune pitié. Avez-vous vraiment besoin de tous les champs dans tous les objets que vous venez d'envoyer? De même, essayez de ne pas envoyer d'objets Client -> Serveur dont vous n'avez pas besoin. Il est souvent plus efficace d'envoyer uniquement une clé qui identifie un objet plutôt que l'intégralité de l'objet lui-même. En outre, vous pouvez améliorer les performances en envoyant uniquement les objets de données au client (et leurs champs respectifs) qui seront affichés à l'écran et reporter le coût des autres jusqu'à ce qu'ils soient réellement requis. (c.-à-d., pagination de données)

LCDS fournit cette out-of-the-box, cependant, pour BlazeDS, vous pouvez utiliser soit dpHibernate ou Gilead pour cela.

(Divulgation: Je suis sur l'équipe dpHibernate)