2010-12-10 26 views
4

Je travaille sur un projet dans lequel un client Silverlight 4 appelle un service Web WCF qui renvoie une grande quantité de données. Certains profilage a révélé queLiaison WCF la plus rapide pour Silverlight 4

  • exécution réelle de la méthode de service Web prend moins d'une seconde (appelle un autre serveur/génère un ensemble de données très large/etc., Il est déjà assez optimisé là) le transfert de données

  • dépend sur le réseau, mais n'est généralement pas un problème -il peut prendre tout ce dont il a besoin

  • temps entre le client reçoit la réponse http (je le vois comme terminé dans Fiddler) et l'événement Terminé tiré dans le client Silverlight: ~ 15 secondes (pas de différence entre IE/firefox/chrome)

Je suppose que le délai de 15 secondes est en grande partie passé à la désérialisation.

Ma liaison utilise HttpTransport et BinaryMessageEncoding, avec une compression gzip par-dessus. La compression Gzip ne semble pas avoir d'impact sur les performances: la différence entre pas de compression et niveau de compression maximum est quasiment inexistante. La réponse http est ~ 15 Mo non compressé et ~ 400 Ko compressé (beaucoup de frais généraux même avec le XML binaire!)

Remarque: le service Web est complètement ad hoc, je ne suis pas intéressé par l'interopérabilité et ai une totale liberté dans le choix du protocole.

Une solution évidente serait de transférer moins de données, mais l'introduction de la pagination nécessiterait des changements majeurs dans l'architecture qui ne sont pas réalisables à l'heure actuelle. La réduction de l'ensemble de données est également assez difficile car la solution est entièrement personnalisable par l'utilisateur final, et comme vous le savez, les utilisateurs ne savent pas toujours ce qu'ils font et finissent par créer des requêtes énormes. Je me retrouve avec la liaison wcf: ce projet a commencé avec SL 2 et a évolué à travers SL 3 et SL 4, alors peut-être que je manque une sorte de liaison plus rapide introduite dans Silverlight 4. Y at-il un autre encodeur plus rapide (ou liaison) je peux utiliser pour éviter le goulot d'étranglement de désérialisation sur le client?

Répondre

2

Que diriez-vous de "tricher" (Améliorant seulement la représentation priée)?

Renvoyez un petit sous-ensemble de données lors du premier appel, puis lancez un processus d'arrière-plan pour récupérer tout ce dont vous avez besoin. Si les données que vous affichez sont en lecture seule, cela pourrait aider. Editer: Regardez la liaison de priorité ... Elle vous permet de lier plusieurs sources de données à votre grille. Si la connexion lente revient plus tard, Silverlight liera automatiquement la nouvelle source de données ...

+0

Ceci est un bon conseil, merci. Je vais certainement mettre en œuvre quelque chose de similaire si je ne peux pas améliorer la performance réelle. –

+0

Bon conseil. Mais cela ne serait-il pas très similaire à la pagination. Je veux dire que si votre processus en arrière-plan ne récupère des données que lorsqu'il doit les afficher, il est plus ou moins paginé. –

+0

L'arrière-plan peut extraire toutes les données (si cela est nécessaire - ce qui est une autre histoire ...) Il peut ensuite remplir l'interface utilisateur avec toutes les entrées, ce qui n'est pas la même chose que la pagination. La pagination fournit un nombre limité d'éléments à l'utilisateur. Mais habituellement, je voudrais savoir pourquoi un utilisateur a besoin de toutes les données. Il peut également s'agir d'un problème d'actualisation avec l'application ... Si le rendu est plus important que nécessaire, il peut également ralentir jusqu'à l'analyse.À quelle heure faut-il que l'appel de service Web aboutisse (Durée dans la trace du violoniste par rapport à l'événement terminé dans SL). Vous pourriez avoir besoin de profilage là-bas ... –