[Pattern][Event] Comment prendre en compte les évènements programmés ? [Résolu]

[kolodz]

Bonjour,


J'ai une question de conception à vous poser. Je vais vous le poser sous forme de problème, pour ne pas être influencer par la technologie utiliser.

Soit un bâtiment qui produit X unité de ressource toutes les heures.

Pour mettre à jour le nombre d'unité disponible, on prend le delta entre la dernière mise à jours et la mise à jours actuelle. Pour avoir quelque chose dans ce style :

Code :

Ressource_Dispo = Ressource_Dispo + (Production_Bâtiment * Delta / 3600)

(Si Delta en seconde)

Le problème vient maintenant :
Si posons qu'on programme un Event entre la dernière mise à jour et notre mise à jours qui change la production du bâtiment.
On connait sa date et les changements que cette Event va produire. Mais nous ne pouvons pas réaliser la modification au moment théorie où va se produire cette Event. Mais seulement lors de notre mise à jours.

La question que je me pose est :

• Comment prendre en compte les évènements programmées quand on ne peux pas les réaliser à la date prévue ?
• Quel Pattern est adapté à la résolution de ce problème ?

J'ai pensé à la solution suivante :

Code :

1
2
3
4
5
6
7
1. Mise à jours des ressources
1.A Recherche des Event à réaliser
Pour tout les Event E
1.A.1 Mise à jours des ressources entre la dernière mise à jour et l'Event E
1.A.2  Réalisation de l'Event E
1.B Mise à jours des ressources entre dernière mise à jour et maintenant.

Cela me fait penser au pattern "Command pattern"

Mais je ne suis pas sûr...

Si vous avez des pistes sur cela ! Je prends aussi tout les commentaires !

Cordialement,
Patrick Kolodziejczyk.

[kain_tn]

Bonjour,

Ta méthode est tout à fait valable et est assez répandue: tu programme tes évènements de telle façon qu'ils s'exécutent, et lorsqu'ils ont fini de s'exécuter ils ajoutent un message à une file d'attente (JMS, table de jobs en BDD, ...).

Lors d'une mise à jour, tu commence par la mise à jour puis tu dépile cette file d'attente pour jouer les messages et modifier les données comme il faut.

L'avantage est que tes évènements sont indépendants (couplage faible et indépendance technologique) de la partie qui effectue la mise à jour.

[kolodz]

Merci beaucoup pour cette réponse !

Du coup,

Je me pose une question sur la gestion des échelles.

Si on prend un système très large, si on reprend mon exemple du bâtiment qui produit.
Si on multiplie le nombre de bâtiment qui produit. (un million par exemple)
Et qu'on conditionne l'effet/déclenchement d'un évènement par la production d'un bâtiment.

Dans la solution que j'ai, je mets l'ensemble de la production des bâtiments à jours, avant de réaliser mon event.
Ce qui peut prendre un temps assez long...

Dois-je altérer la solution en ajoutant aux Event les bâtiments qui doivent être mise à jours avant leur exécution ?

Cela complexifie légèrement la solution, mais permet d'avoir quelque chose d'un peu moins coûteux en ressource.

Cordialement,
Patrick Kolodziejczyk.

[pseudocode]

S'il y a beaucoup d'entité à mettre à jour, je changerais la manière d'organiser les mises à jour.

Par exemple en créant des objets "Mise à jour" (un pour chaque bâtiment), et en ajoutant les évènements dans les objets "Mise à jour".

On peut alors traiter séparément chaque mise à jour (parallélisation, priorité, ...)

[kolodz]

Très bonne idées !
Cela évite la recherche des évènements à exécuter pour un bâtiment donner.
Surtout que cela représente la plus grande partie du temps de calcule dans le processus que j'ai testé :

Sur une implémentation Java, on obtient des résultats très différents entre la première solution et la seconde :

Premier cas de test :

nombre de building = 1000;
nombre d'event = 20000;
1 event : Une cible, Deux Bâtiment à mettre à jour (dont la cible)

Résultat :

Envoyé par Event General

Time to process one building 12449 ms on 1000
With 28787 building updates and 14393 events done
Time on find events 11413 ms
Time to process all buildings 1130 ms on 1000
With 12214 building updates and 5607 events done
Time on find events 1041 ms

Envoyé par Event building

Time to process one building 123 ms on 1000
With 28183 building updates and 14091 events done
Time on find events 42 ms
Time to process all buildings 28 ms on 1000
With 12818 building updates and 5909 events done
Time on find events 7 ms

Second cas de test :

nombre de building = 100000;
nombre d'event = 100000;
1 event : Une cible, Deux Bâtiment à mettre à jour (dont la cible)

Envoyé par Event General

Time to process one building 26 ms on 100000
With 1 building updates and 0 events done
Time on find events 24 ms
Time to process all buildings 1172393 ms on 100000
With 300000 building updates and 100000 events done
Time on find events 1143782 ms

Envoyé par Event building

Time to process one building 2 ms on 100000
With 1 building updates and 0 events done
Time on find events 1 ms
Time to process all buildings 671 ms on 100000
With 300000 building updates and 100000 events done
Time on find events 106 ms

Il est clair que la localisation des évènements dans le programme, leur gestion impacte directement les performances générales de l'application.

Cordialement,
Patrick Kolodziejczyk.