Taille de paramètre maximale pour le service WCF

Question

Avoir un service WCF (hébergé dans IIS 6.0) qui prend un flux XML à partir de SAP avec potentiellement des dizaines de milliers (ou plus) d'enregistrements à traiter.

[OperationContract] 
[FaultContractAttribute(typeof (ArgumentException))] 
void ProcessSapRoles(XElement SapData); 

Je suis préoccupé par les limitations sur les tailles de paramètres. D'autres articles de SO, je suis en train de lire que l'augmentation de maxRequestLength sur le paramètre httpRuntime dans le web.config aidera cela (je suis sûr que je vais devoir augmenter le délai d'envoi, aussi bien). J'ai également lu que l'aide d'un NetTcpBinding aidera, bien que je ne connaisse pas les limitations pour l'utiliser ou comment le configurer. Je suppose que je pourrais demander 100 000 appels à l'appelant, un par enregistrement, mais je pense que l'impact sur les performances serait important. En outre, d'un autre côté, je dois interroger les enregistrements existants pour voir si je mets à jour ou ajouter des enregistrements, puis renvoyer les mises à jour à la base de données. La création de 100 000 ensembles de données pour 100 000 requêtes séparées d'un enregistrement semble également rédhibitoire.

pré-WCF, nous avons utilisé des puits de compression sur une chaîne de communication à distance, ce qui considérablement des performances accrues (l'envoi de nos plus grands ensembles de données ont été chronogrammes sur la page Web après 20 minutes, après avoir ajouté le puits de compression, les jeux de données traversaient le fil en environ 20 secondes) (et le client était responsable de la création de jeux de données de cette taille, nous n'avions aucun contrôle sur eux: P).

Comment gérer au mieux le transfert de 100 000 enregistrements, et existe-t-il un concept équivalent d'un récepteur de compression pour WCF?

TIA!
James

Answer 1

Les services WCF sont limités à 64 Ko en taille de paramètre - par défaut. C'est pour une bonne raison - le service devra avoir un tampon (ou potentiellement plusieurs tampons, pour les appelants simultanés) de cette taille, et si cette taille est trop grande, on pourrait facilement inonder un serveur avec d'énormes requêtes et l'amener à genoux. Peu importe la quantité de RAM que vous avez, à un moment donné, il n'y en aura plus. MAIS: la bonne chose est: comme à peu près tout, vous pouvez configurer cela assez facilement. Si vous combinez une grande taille de message avec le NetTcpBinding hautement optimisé dans un environnement LAN d'entreprise (derrière des pare-feu), vous devriez être sûr et vous devriez pouvoir transmettre à peu près n'importe quel document de taille entre votre client et un service.

Answer 2

Avez-vous envisagé d'utiliser Streaming in WCF pour transférer des données volumineuses?

Sur une note de côté, NetTcp aidera absolument. La raison est qu'il utilise Binary encoding par défaut. D'autre part, Http utilise par défaut Text encoding qui a besoin d'espace supplémentaire.