Discussion :

[Vonotar]

Hello à tous,

l'architecture d'un de mes projets se décompose ainsi:
- Une application serveur accédant à une DB SQL Server 2005,
- Plusieurs applications clientes de production (industrielle) peu gourmandes,
- Une application cliente de reporting (bureaux) assez gourmande.

Les clients communiquent avec mon application serveur via le .Net Remoting.

Pour l'instant, lorsque la production travaille (environ 16 postes en même temps), je n'ai aucun problème de performance. Par contre, dès qu'un employé veut un rapport, dès que la demande est faite au remoting, le reste de la production est ralentie à cause de ça.

Quelqu'un a-t-il déjà été confronté à ce type de problème ? (et surtout, comment l'avez-vous résolu ?)
Je me demandais comment je pourrais définir des priorités au niveau des demandes faites au serveur (car le but est de ne pas ennuyer la production, le fait qu'un rapport prenne 10 secondes en plus à charger n'étant pas un soucis). Mais j'ai lu qu'on ne pouvait pas définir des priorités via .Net Remoting. Qu'en est-il réellement ?

Merci beaucoup à qui pourra m'aider ou me donner des pistes de recherche,
Vonotar.

[SaumonAgile]

Si le problème ne vient pas de la source de données qui pourrait être surchargée, tu pourrais pas être utiliser deux serveurs, un pour la production et un pour les rapports.
Dans le cas contraire, si le problème vient de la source de données, il faudrait peut-être songer à upgrader le matériel, et peut-être séparer en plusieurs sources, une pour la production et une pour les rapports.
Si c'est possible, tu peux aussi prégénérer les rapports la nuit et les rendre dispo aux utilisateurs sans avoir besoin de les regénérer à chaque fois.

[cinemania]

Il n"y a pas de moyen de définir les priorités certes, mais tout dépend aussi comment tu développe tes webservices et les clients qui les consommes.

En fait je ne vois pas du tout l'intérêt de développer des priorités, ca ne changerais rien au problème.
Tant que tu n'a pas isoler clairement quelle partie pose problème... tout le reste n'est que pure spéculation.

Pour mieux cerner le problème, il faut savoir si les connexions clientes "business" utilisent également la base de données, ou si c'est seulement le client "reporting".

Ensuite comme il a été dit, je te suggère vivement de mettre en place une précompilation du rapport. En effet, si celui-ci est basé sur des données qui changent une fois par jour (la nuit, comme une remontée SAP par exemple)
une fois ces données mises à jour, tu relance un process de compilation du rapport, ou des rapports, dans des tables "dédiées", quitte à ajouter sur des colonnes des index pour le filtrage ... si ton reporting est basé sur une série de données de filtrage.

Ainsi la journée lors de la génération du rapport, tu minimisera le temps utilisé coté SGBD. Cependant, il faut aussi ce rendre compte que la partie mise en forme qui se fait toujours coté serveur, va encombrer le système... mais pour cela le seigneur à inventer des trucs hyper sympa.... les THREADs...
loué soit le seigneur.

En général qui dit architecture distribuée devrait dire également architecture MASSIVEMENT multithread. Malheureusement c'est rarement le cas, et c'est fort domage

Si tu utilise des threads et des mécanismes asynchrones avec delegate dans tes "services" tu n'aura moins le probleme des priorités, car un service n'occupera le système que lorsqu'il communiquera avec le client, soit au lancement de la requete et à la fin quand les données sont prêtes, soit un minimum que pour du transfert d'informations.

Maintenant c'est vrai je reconnais, c'est tellement moins drôle une architecture multithread... car faut penser synchronisation, tous ces trucs qui donnent des mots de cranes aux pauvres développeurs que nous sommes...
Mais il faut ce qui faut ! Après tout on ne fait pas d'omelette sans casser des neufs...

Ah oui j'oubliais... puisque visiblement tu en est à vouloir grappiller des millisecondes et des secondes par ci par là...
Un développement microsoft avait déposé sur son blog un benchmark comparatif des technologies WCF / NET Remoting.

Globallement il en résulte qu'il est plus rentable de faire un serveur avec WCF, car les délais de réponse sont de l'ordre de 32ms de façon permanente.
Et qu'il est préférable de consommer le service avec du .NET Remoting. L'association permet d'obtenir des temps allant de 32 à 64ms, et 200ms lors de l'initialisation et de la première consommation du webservice contre plus d'une seconde avec le tout en .NET Remoting, et carrément 24s avec le tout en WCF.
Cela dit, après tout dépend de ton besoin, et de si oui ou non tu peux déployer le .NET3.0 au moins sur le serveur.
Je ne saurais trop te conseiller de faire un serveur avec WCF. Déjà c'est beaucoup plus simple à développer... pas besoin d'hériter ta classe d'implantation de MarshalByRef tu peux la faire hériter de ce que tu veux.