Discussion :

[zitoun]

Bonjour,
Je dois créer un objet qui permet de fournir des données en temps réel sur l’état d'une machine.
Ce que je fait actuellement c'est que j'interroge a intervalle régulier les capteurs de la machine, je traite l'info et puis je génère des évènement en fonction des données.
Mais voilà cette solution n'est pas optimale et me crée des problème de performance.

quelqu'un pourrait me dire comment faire pour optimiser tout ça (pas forcement une solution prête mais des idées...), sachant que l'appli consommatrice de ce flux est en WPF, je pourrais peut être profiter du binding...?

Merci.

[tomlev]

Mais voilà cette solution n'est pas optimale et me crée des problème de performance.

Je ne vois rien de fondamentalement mauvais dans ton approche...

Tu pourrais éventuellement inverser le fonctionnement du système, en faisant que la machine surveillée envoie elle-même les infos des capteurs (push). .NET 4 fournit des interfaces pour ce genre de choses : IObservable<T> et IObserver<T> (couplé à Linq et Reactive Extensions, ça permet de faire des choses sympa). Mais je ne vois pas trop en quoi ça améliorerait les performances, sauf si l'état des capteurs ne changent pas trop souvent (comme ça la machine n'envoie des notifications que s'il y a un changement).

A quel niveau as-tu des problèmes de perfs ? Tu as essayé de profiler pour voir d'où ça venait ? Peut-être que ton approche est correcte mais qu'il y a des problèmes dans l'implémentation

sachant que l'appli consommatrice de ce flux est en WPF, je pourrais peut être profiter du binding...?

Tu pourrais, mais ça ne changerait pas vraiment le fond du problème à mon avis...

[zitoun]

Je ne vois rien de fondamentalement mauvais dans ton approche...

Tu pourrais éventuellement inverser le fonctionnement du système, en faisant que la machine surveillée envoie elle-même les infos des capteurs (push). .NET 4 fournit des interfaces pour ce genre de choses : IObservable<T> et IObserver<T> (couplé à Linq et Reactive Extensions, ça permet de faire des choses sympa). Mais je ne vois pas trop en quoi ça améliorerait les performances, sauf si l'état des capteurs ne changent pas trop souvent (comme ça la machine n'envoie des notifications que s'il y a un changement).

A quel niveau as-tu des problèmes de perfs ? Tu as essayé de profiler pour voir d'où ça venait ? Peut-être que ton approche est correcte mais qu'il y a des problèmes dans l'implémentation



Tu pourrais, mais ça ne changerait pas vraiment le fond du problème à mon avis...

Merci,
Il semblerait que le problème soit le nombre élevé d’évènement.
Le IObservable<T> et IObserver<T> semble intéressant. Je vais tenter des choses avec.

[hegros]

Je dois créer un objet qui permet de fournir des données en temps réel sur l’état d'une machine.

Quel objet ? La question est quel est ton architecture notamment comment consomme,ta vue WPF, les données d'acquisition. Web service ? buffer d'une base de données (dataset)? ... ?

Ce que je fait actuellement c'est que j'interroge a intervalle régulier les capteurs de la machine, je traite l'info et puis je génère des évènement en fonction des données.
Mais voilà cette solution n'est pas optimale et me crée des problème de performance.

Dans quel cas de fonctionnement (nombre de machine, nombre de capteurs) les performances ne sont pas acceptables ?C'est de l'acquisition par pooling et tu génères un événement quand une valeur change par exemple ?

Cela peut effectivement poser des problèmes de performance si tu passes ton temps à générer des événements (si tu as beaucoup de données de capteurs qui changent).

Il faut en savoir plus sur ton architecture entre l'acquisition et la vue WPF. Notamment les contraintes de temps (réel) pour le rafraîchissement de la vue en fonction d'une donnée

Une approche plus optimale serait de regrouper les données par période. Ainsi tu 'garantis' un nombre d'événements constants dans le temps pour un groupe de données constant(période de temps par exemple toutes les 10 minutes)

Coupler au pattern Observateur cela me semble une idée à tester (sachant qu'il n'y aura qu'un observateur (la vue wpf))

[zitoun]

Quel objet ? La question est quel est ton architecture notamment comment consomme,ta vue WPF, les données d'acquisition. Web service ? buffer d'une base de données (dataset)? ... ?




Dans quel cas de fonctionnement (nombre de machine, nombre de capteurs) les performances ne sont pas acceptables ?C'est de l'acquisition par pooling et tu génères un événement quand une valeur change par exemple ?

Cela peut effectivement poser des problèmes de performance si tu passes ton temps à générer des événements (si tu as beaucoup de données de capteurs qui changent).

Il faut en savoir plus sur ton architecture entre l'acquisition et la vue WPF. Notamment les contraintes de temps (réel) pour le rafraîchissement de la vue en fonction d'une donnée

Une approche plus optimale serait de regrouper les données par période. Ainsi tu 'garantis' un nombre d'événements constants dans le temps pour un groupe de données constant(période de temps par exemple toutes les 10 minutes)

Coupler au pattern Observateur cela me semble une idée à tester (sachant qu'il n'y aura qu'un observateur (la vue wpf))

Grossomodo l'architecture se resume a un Ecran de monitoring avec tout les indicateur nécessaires (le view), un controlleur qui implémente INotifyPropertyChanged (le viewModel). Un gestionnaire de donnée (Model) qui instancie un moteur (engine) qui s'execute dans un backgroundworker et a chaque fois qu'il trouve des donnée génère toutes sortes d'evenement porteurs de donnée.

- Le view a pour dataContext le viewModel
- Les propriétes du viewModel sont des double, int, DateTime et des ObservableCollection.
- Les differents champs du view sont bindés au propriétés du viewModel.
- Le Model s'inscrit a tout les evenement de l'engire et update le viewModel a chaque fois que l'engine le notifie.
- L'engine execute a intervalle regulier un traitement qui interroge via une API fournie par le constructeur les capteurs de la machine.

voilà voilà...
J'espère que c'est compréhensible.

Si je trouve rien je penserai peut être a diminuer la fréquence d’exécution de mon engine.

Merci.

[hegros]

Grossomodo l'architecture se resume a un Ecran de monitoring avec tout les indicateur nécessaires (le view), un controlleur qui implémente INotifyPropertyChanged (le viewModel). Un gestionnaire de donnée (Model) qui instancie un moteur (engine) qui s'execute dans un backgroundworker et a chaque fois qu'il trouve des donnée génère toutes sortes d'evenement porteurs de donnée.

Un peu bizarre que le modèle instancie l'engine l'inverse me semble plus logique (grasp pattern création) ou alors le controlleur.

- Le view a pour dataContext le viewModel
- Les propriétes du viewModel sont des double, int, DateTime et des ObservableCollection.
- Les differents champs du view sont bindés au propriétés du viewModel.
- Le Model s'inscrit a tout les evenement de l'engire et update le viewModel a chaque fois que l'engine le notifie.
- L'engine execute a intervalle regulier un traitement qui interroge via une API fournie par le constructeur les capteurs de la machine.
J'espère que c'est compréhensible.

Oui c'est très clair comme description.

Si je trouve rien je penserai peut être a diminuer la fréquence d’exécution de mon engine.

Est-ce que tu gères une bande morte ? C'est à dire que les notifications se font lorsque la valeur courante d'une donnée change d'un certain seuil par rapport à la précédente acquise ?

C'est quoi aujourd'hui la fréquence d'exécution des notifications, combien de réseaux d'équipements en moyenne et quelle protocole de communication (si c'est du série à 900bauds il faut déjà plusieurs (minutes) pour acquérir une donnée...)

Augmenter la fréquence c'est bien mais tu n'as pas de contrainte de temps pour rafraîchir une donnée sur la vue ? Parce qu'il y a quoi sur la vue des données sur des stocks qui peuvent attendre 10heures pour se rafraîchir ou alors une valeur d'une pression dans une centrale nucléaire ?

Il faut chercher une solution déterministe pour le rafraîchissement car si le nombre d'équipements est important ou la vitesse de communication trop lente il faut prendre en compte ce "temps en plus" d'acquisition dans le décompte pour la mise à jour de la vue