2009-09-10 3 views
0

J'ai un projet 3.5 SP1, service WCF qui est limité à la consommation par les clients Silverlight 3. En raison des besoins de l'entreprise, nous devons travailler avec de grands graphiques d'objets qui sont hydratés via SQL Server du côté de la WCF, puis envoyés au client Silverlight. Ils sont profonds, vous pourriez avoir une classe qui a deux propriétés de collection et chaque élément de la collection a des collections à l'intérieur. La conception fondamentale est ce qu'elle est, quelque chose dont j'ai hérité et que je dois travailler à court terme. De quelle taille parlons-nous? Un exemple de collection de niveau supérieur avec 250 éléments une fois sérialisés est de 14 Mo en traversant le réseau sans aucune modification (httpBinding et le DataContractSerializer). 250 articles sont petits, les exigences auxquelles nous sommes confrontés nous obligent à être en mesure de travailler avec plus de 10.000 articles qui, compte tenu de mes compétences en mathématiques limitées est bien au-dessus de 500mb pour tirer à travers le fil. Aucune promenade dans le parc - en fait - vous pourriez probablement faire une promenade dans le parc pendant que baratté loin. Il y a plusieurs choses que nous considérons, l'une est de quitter DataContractSerializer et d'utiliser XmlSerializer pour pouvoir déplacer beaucoup de ces propriétés dans les attributs et réduire la taille de la charge utile. Nous examinons également les liaisons Binary Xml.Comment accélérer la sérialisation et le transport pour les grands graphiques d'objets; WCF 3.5 & SL3

Ma question est la suivante, que feriez-vous? La compression IIS peut-elle jouer un rôle ici? S'éloigner du DCS est une mauvaise idée? Y a-t-il une meilleure technique? Suis-je dans une crique sans pagaie?

Répondre

0

Avez-vous absolument besoin de pour abattre toutes ces données en une seule fois? S'il s'agit d'une application Silverlight, je ne peux pas vous voir afficher physiquement plus de 10 000 enregistrements (ou même 250 d'ailleurs) de la taille que vous décrivez. Est-il possible d'utiliser la pagination pour réduire la quantité de données tirées à travers le fil? Au lieu d'avoir 10 000+, vous pourriez afficher 10-20 enregistrements par page, de sorte que le système interroge seulement 10-20 selon les circonstances.

Je ne sais pas si c'est une option pour vous, compte tenu des exigences que vous décrivez, mais cela semble être la solution la plus évidente pour moi.


En outre, pour aider marginalement vos performances, avez-vous assuriez serialization assemblies are being generated pour vos objets métier? Cela permettrait d'optimiser au moins la partie sérialisation/désérialisation de votre code. Ce ne sera peut-être pas un énorme coup de pouce, mais cela aidera.

+0

à long terme je factoriser les choses de sorte que seuls les éléments dont j'ai besoin dans un ensemble de données viennent à travers le fil, mais la réalité est que pour l'instant, nous avons des exigences de cartographie considérables qui nous obligent à agir sur les données du côté SL. J'ai besoin de tous les éléments 10K parce que divers éléments d'entre eux sont utilisés pour différents éléments de la carte et leurs objets enfants sont nécessaires pour les agrégats et autres. – keithwarren7

Questions connexes